[OpenSIPS-Users] R: R: Can anyone help me?!?
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Wed Feb 11 15:09:42 CET 2009
So, I understand it work ok now, right?
Regards,
Bogdan
Mauro Davi' wrote:
> Thanks very much....
>
> MD
> -----Messaggio originale-----
> Da: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro]
> Inviato: mercoledì 11 febbraio 2009 13:35
> A: Mauro Davi'
> Cc: users at lists.opensips.org
> Oggetto: Re: R: [OpenSIPS-Users] Can anyone help me?!?
>
> Hi Mauro,
>
> The problem seams to be on UAS.
>
> UAS received in contact:
> Contact: <sip:user2 at 192.168.193.71:28278;rinstance=92f44431ebda131f>
>
> But is sends out:
> Contact: <sip:user2 at 192.168.193.73:4530;rinstance=92f44431ebda131f>
>
> probably in the UAS cfg you do some fix_nated_contact() in onreply_route....
>
> Regards,
> Bogdan
>
> Mauro Davi' wrote:
>
>> Hi Bogdan,
>>
>> In attach there are the scripts files.
>>
>> The load balancer route the INVITE request message to the sip server if it received from an UAC otherwise it sent the request to the appropriate client using a t_relay function.
>> All the subsequent message are routed in the loose_routed branch (also the ACK request message).
>>
>> below the 200 OK messagges sent by UAC2 to the proxy->server->proxy->UAC1.
>>
>> UAC1 (.54) Proxy (.73:4530) UAS (.75:5060) UAC2(.71)
>> | | | 200 OK SDP (1) |
>> | |<----------------------------------------|
>> | | 200 OK SDP (2) | |
>> | |---------------->| |
>> | | 200 OK SDP (3) | |
>> | |<----------------| |
>> | 200 OK SDP (4) | | |
>> |<-------------------| | |
>>
>> Message 200 OK from UAC2 -> Proxy (1)
>>
>> 2.0 200 OK
>> Via: SIP/2.0/UDP 192.168.193.73:4530;branch=z9hG4bKd8c4.6d562f91.0
>> Via: SIP/2.0/UDP 192.168.193.75;rport=5060;received=192.168.193.75;branch=z9hG4bKd8c4.a96eeb3.0
>> Via: SIP/2.0/UDP 192.168.193.73:4530;rport=4530;received=192.168.193.73;branch=z9hG4bKd8c4.5d562f91.0
>> Via: SIP/2.0/UDP 192.168.193.54:11780;received=192.168.193.54;branch=z9hG4bK-d8754z-843ba81c62397b3c-1---d8754z-;rport=11780
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.75;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Contact: <sip:user2 at 192.168.193.71:28278;rinstance=92f44431ebda131f>
>> To: <sip:user2 at domain.com>;tag=0f0b9372
>> From: <sip:user1 at domain.com>;tag=a82ddc47
>> Call-ID: Y2Q3Njc0MjE0M2I2Mjk3NWQ0ZDNiNjI0YzAxMjgwNjI.
>> CSeq: 2 INVITE
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
>> Content-Type: application/sdp
>> User-Agent: Bria release 2.4.3 stamp 50900
>> Content-Length: 488
>>
>> Message 200 OK from Proxy -> UAS (2)
>>
>> [SDP payload]
>>
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 192.168.193.75;rport=5060;received=192.168.193.75;branch=z9hG4bKd8c4.a96eeb3.0
>> Via: SIP/2.0/UDP 192.168.193.73:4530;rport=4530;received=192.168.193.73;branch=z9hG4bKd8c4.5d562f91.0
>> Via: SIP/2.0/UDP 192.168.193.54:11780;received=192.168.193.54;branch=z9hG4bK-d8754z-843ba81c62397b3c-1---d8754z-;rport=11780
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.75;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Contact: <sip:user2 at 192.168.193.71:28278;rinstance=92f44431ebda131f>
>> To: <sip:user2 at domain.com>;tag=0f0b9372
>> From: <sip:user1 at domain.com>;tag=a82ddc47
>> Call-ID: Y2Q3Njc0MjE0M2I2Mjk3NWQ0ZDNiNjI0YzAxMjgwNjI.
>> CSeq: 2 INVITE
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
>> Content-Type: application/sdp
>> User-Agent: Bria release 2.4.3 stamp 50900
>> Content-Length: 488
>>
>> [SDP payload]
>>
>> Message 200 OK from UAS -> Proxy(3)
>>
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 192.168.193.73:4530;rport=4530;received=192.168.193.73;branch=z9hG4bKd8c4.5d562f91.0
>> Via: SIP/2.0/UDP 192.168.193.54:11780;received=192.168.193.54;branch=z9hG4bK-d8754z-843ba81c62397b3c-1---d8754z-;rport=11780
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.75;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Contact: <sip:user2 at 192.168.193.73:4530;rinstance=92f44431ebda131f>
>> To: <sip:user2 at domain.com>;tag=0f0b9372
>> From: <sip:user1 at domain.com>;tag=a82ddc47
>> Call-ID: Y2Q3Njc0MjE0M2I2Mjk3NWQ0ZDNiNjI0YzAxMjgwNjI.
>> CSeq: 2 INVITE
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
>> Content-Type: application/sdp
>> User-Agent: Bria release 2.4.3 stamp 50900
>> Content-Length: 488
>>
>> [SDP payload]
>>
>> Message 200 OK from Proxy -> UAC1(4)
>>
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 192.168.193.54:11780;received=192.168.193.54;branch=z9hG4bK-d8754z-843ba81c62397b3c-1---d8754z-;rport=11780
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.75;lr;ftag=a82ddc47;nat=yes>
>> Record-Route: <sip:192.168.193.73:4530;lr;ftag=a82ddc47;nat=yes>
>> Contact: <sip:user2 at 192.168.193.75:5060;rinstance=92f44431ebda131f>
>> To: <sip:user2 at domain.com>;tag=0f0b9372
>> From: <sip:user1 at domain.com>;tag=a82ddc47
>> Call-ID: Y2Q3Njc0MjE0M2I2Mjk3NWQ0ZDNiNjI0YzAxMjgwNjI.
>> CSeq: 2 INVITE
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
>> Content-Type: application/sdp
>> User-Agent: Bria release 2.4.3 stamp 50900
>> Content-Length: 488
>>
>> [SDP payload]
>>
>> The 200 OK message wad modified a first time by the server and a second time by the proxy. I think that all the job are done by the TM module...
>>
>> Best regards and Thanks so much.
>>
>> MD
>>
>> -----Messaggio originale-----
>> Da: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro]
>> Inviato: martedì 10 febbraio 2009 12:58
>> A: Mauro Davi'
>> Cc: users at lists.opensips.org
>> Oggetto: Re: [OpenSIPS-Users] Can anyone help me?!?
>>
>> Hello Mauro,
>>
>> Please post the 200 OK received by the UA1 from the SIP proxy . This is
>> strange is that the ACK has in RURI the IP of the SIP Server (.75),
>> instead of the IP of the UA2.
>>
>> A possibility is that the Contact from 200 OK (which will be used as
>> RURI for ACK) to be re-written by one of the parties....I suspect that
>> SIP proxy is doing that....try to follow the whole path of the 200 OK
>> from UA2 to UA1 and see where the contact is replaced.
>>
>> Regards,
>> Bogdan
>>
>> Mauro Davi' wrote:
>>
>>
>>> Hi All,
>>>
>>> I setting Up an architecture with a SIP Proxy that using the dispatcher module to
>>> balance the incoming traffic on several SIP Servers.
>>>
>>>
>>> +----------+ +----------+
>>> | UA1 | | UA2 |
>>> +----------+ +----------+
>>> ^ | ^ |
>>> | V | V
>>> +--------------------------------+
>>> | SIP Proxy |
>>> +--------------------------------+
>>> ^ |
>>> | V
>>> +------------------+
>>> | SIP Server (UAS) |
>>> +------------------+
>>>
>>> The SIP Proxy is an opensips server configured with the opensipslbnew.cfg file attached.
>>> The SIP Server is an opensips server configured with the opensipsservernew.cfg file attached.
>>>
>>> UAC1 (.54) Proxy (.73:4530) UAS (.75:5060) UAC2 (.71)
>>> | INVITE | | |
>>> |------------------->| | |
>>> | 100 Trying | | |
>>> |<-------------------| INVITE | |
>>> | |---------------->| |
>>> | | 100 Trying | |
>>> | |<----------------| |
>>> | | INVITE | |
>>> | |<----------------| |
>>> | | 100 Trying | |
>>> | |---------------->| |
>>> | | | INVITE |
>>> | |---------------------------------------->|
>>> | | 180 RINGING | |
>>> | |<----------------------------------------|
>>> | | 180 RINGING | |
>>> | |---------------->| |
>>> | | 180 RINGING | |
>>> | |<----------------| |
>>> | 180 RINGING | | |
>>> |<-------------------------------------| |
>>> | | | 200 OK SDP |
>>> | |<----------------------------------------|
>>> | | 200 OK SDP | |
>>> | |---------------->| |
>>> | | 200 OK SDP | |
>>> | |<----------------| |
>>> | 200 OK SDP | | |
>>> |<-------------------------------------| |
>>> | | | |
>>> | ACK (1) | | |
>>> |------------------->| | |
>>> | | ACK (2) | |
>>> | |---------------->| |
>>> | | ACK (3) | |
>>> | | +-| |
>>> | | +>| |
>>> | | ACK (4) | |
>>> | |<----------------| |
>>> | | | |
>>>
>>> During the setup phase (i.e. the INVITE message), the flow messages
>>> seems to be correct, but when
>>>
>>>
More information about the Users
mailing list