[OpenSIPS-Users] 302 handling in openser

[sai at 800pbx.com]

Hi Bogdan,

Thanks very much for volunteering to take care of it. I have logged in a
bug :

[ 2056761 ] maddr handling in 302 response

but I did not assign it to you. Hope you will do that.

A small note to the problem:
Using uri.maddr field will not work in this case as the maddr field is not
part of a URI but the CONTACT header.

Thank you very much for the response.

Regards,
Sai.


> Hi Sai,
>
> i'm aware of the lack of support of maddr in opensips  - please uploaded
> as a bug report on the tracker and I will take care of it asap.
>     http://sourceforge.net/tracker/?atid=1086410&group_id=232389&func=browse
>
> Thanks and regards,
> Bogdan
>
> sai at 800pbx.com wrote:
>> The maddr field is in the CONTACT header and we need to extract the ip
>> address in the maddr field.
>>
>> Regards,
>> Sai.
>>
>>
>>> 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.
>>>
>>> Please help us in this regard.
>>>
>>> Regards,
>>> Sai.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>