[reSIProcate] Documenting how-to handle 439 outbound not supported case

Aron Rosenberg arosenberg at logitech.com
Fri Apr 1 10:59:54 CDT 2011


All,

I was doing some interop testing with a pstn provider and they have a setup
which results in 439 (first hop doesn't support outbound). My guess is their
SBC is stupid, but their registrar is smart, so I was going to implement the
logic in RFC 5626 4.2.1 in our UAC:

 If the registering UA receives a 439 (First Hop Lacks Outbound
   Support) response to a REGISTER request, it MAY re-attempt
   registration without using the outbound mechanism (subject to local
   policy at the client).


To support this with the current outbound implementation, upon
receiving the 439, you must issue a new makeRegistration with the
outbound pieces of the new UserProfile disabled. Simply turning off
just the features in the existing UserProfile attached to the Handle
and attempting refresh doesn't work.


 void onFailure(ClientRegistrationHandle crh, const SipMessage& msg)

 {

    resip::SharedPtr<UserProfile> up(crh->getUserProfile());

    if(msg.header(h_StatusLine).responseCode() == 439) // 439 means
non outbound supported path to Registrar. Retry without outbound
support.

    {

        up->setInstanceId(Data());

        up->setRegId(0);

        up->clientOutboundEnabled() = false;

	resip::SharedPtr<resip::SipMessage> reg =
dum->makeRegistration(....); // Pass in up, the modified UserProfile

	dum->send(reg);

        return;

    }

    ....

 }


I added this documentation to
https://www.resiprocate.org/DUM_Client_Outbound_Support


Aron Rosenberg
Sr. Director, Engineering
Logitech Inc. (SightSpeed Group)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110401/81077e34/attachment.htm>


More information about the resiprocate-devel mailing list