[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