[OpenSIPS-Devel] [ opensips-Bugs-2056761 ] maddr handling in 302 response

SourceForge.net noreply at sourceforge.net
Mon Aug 18 05:39:16 CEST 2008


Bugs item #2056761, was opened at 2008-08-18 03:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2056761&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: maddr handling in 302 response

Initial Comment:
 We have a setup where we are using Microsoft Speech Server (MSS) to connect to Asterisk through Openser. This was done as MSS uses TCP only and Asterisk only UDP. The connection is something like shown below:

 MSS <---->Openser<--->Asterisk<--->SIP Phones


Now, when a SIP Invite is sent to MSS from SIP UA through openser, Speech server sends back a 302 message containing a maddr field populated with the new IP Address where the UA must contact. This is forwarded back to the SIP UA which doesnt know how to handle this. Moreover, the transport is TCP instead of UDP which creates more problems.

We would like Openser to handle the 302 message and re-direct the Invite message to the new IP address got from the maddr field. How can we populate this through Openser?

In earlier posts, it was mentioned that uac_redirect module can be used to
handle the 302 but how exactly can the maddr field read and Invite
populated with the new IP address is not clear.


In one of the SIP users posts, the maddr usage was mentioned as :

"In some rfc 2543 implementations it had
been used to force an alternative route to the the one specified in R-URI,
however , this is discouraged by the 3261 spec and the loose-routing
mechanism is provided instead."

However, the maddr is still being utilised by systems to populate the alternate routes.

Any help regarding how can we handle the 302 will be useful for us. Using

Transformations module in onreply_route block did not help our cause.

Also, we have tried using replace_body and replace_body_all with hard-coded values for the ip addresses did not do the trick.

The maddr field is in the CONTACT header and we need to extract the ip address in the maddr field.

Using uri.maddr field will not work in this case as the maddr field is not part of a URI but the CONTACT header.

Please help us in this regard.

Regards,
Sai.
(Sai at 800pbx.com)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2056761&group_id=232389



More information about the Devel mailing list