[OpenSIPS-Devel] [ opensips-Bugs-2056761 ] [core+TM] maddr handling in RURI

SourceForge.net noreply at sourceforge.net
Thu Aug 21 12:13:19 CEST 2008


Bugs item #2056761, was opened at 2008-08-18 06:39
Message generated for change (Comment added) made by bogdan_iancu
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: core
Group: 1.4.x
Status: Open
Resolution: Accepted
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [core+TM] maddr handling in RURI

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)


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-08-21 13:13

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Of course you can do a lot of hacks (as the one you mentioned) to fix the
problem, but there are some issues:
  - the maddr usage must be automatically done to ensure proper handling
(as per RFC) - it should not be a user option
  - as an uri with maddr may be used in several places (RURI, contact,
etc), a common place for handling will be better.

The fix does not require such an extensive work, but still there is some
work to be done :)

Regards,
Bogdan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-20 22:17

Message:
Logged In: NO 

Microsoft do the same with 302 and maddr as Nortel with CS1000 and CS2000
clusers to select the active one. So a fix would also solve trouble with
Nortel systems.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-20 18:37

Message:
Logged In: NO 

There's a lot to work on here.  I'll take the easy part.  The body of the
CONTACT header is a URL.  Something along the lines of

$(hdr(CONTACT){s.escape.common}{url.maddr})

should get the value for you if I'm not mistaken.

You also might want to look at grabbing that 302 in a failure route and
using next_contacts and all that rather than a reply route.

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

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