Hi Bogdan, I do see an ack sent back from the gw, however, when new invite is sent openser relays it according to lcr rules but then a 302 is sent back to the gateway.

Would it be better to detect and process the 302 message in openser itself?

Thanks.

--

Packet snippet below.

version: openser 1.1.0-notls (i386/linux)

sip proxy: 1.1.1.1 cisco gw: 2.2.2.2 phone: 3.3.3.3 sip ITSP: 4.4.4.4

302 from proxy to gw

# U 1.1.1.1:5060 -> 2.2.2.2:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. CSeq: 101 INVITE. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Contact: sip:9318001234567@siphost.mydomain.com. Record-Route: sip:1.1.1.1;lr=on;ftag=2F5940AC-583. User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708. Diversion: sip:10562@1.1.1.1;reason="deflection". Content-Length: 0. .

Ack from gw to proxy

# U 2.2.2.2:5060 -> 1.1.1.1:5060 ACK sip:10562@1.1.1.1:5060 SIP/2.0. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. Date: Fri, 30 Mar 2007 15:29:07 GMT. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Max-Forwards: 70. CSeq: 101 ACK. Allow-Events: telephone-event. Content-Length: 0. .

New invite is received and forwarded to ITSP and then 302 is sent from proxy to cisco gw

# U 1.1.1.1:5060 -> 2.2.2.2:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. CSeq: 101 INVITE. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Contact: sip:9318001234567@siphost.mydomain.com. Record-Route: sip:1.1.1.1;lr=on;ftag=2F5940AC-583. User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708. Diversion: sip:10562@1.1.1.1;reason="deflection". Content-Length: 0. .

I am including more packet info below. Please note that I have multiple remote-party-id headers in the invite forwarded to the service provider.

remote-party header is edited as packet is received and has to be edited again before being relayed. I have not been able to undo the first edit or remove it altogether. Any suggestion?

++++++++++++++++++++++++++++++++ U 3.3.3.3:8891 -> 1.1.1.1:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKe22b.4c0e7b31.0. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. CSeq: 101 INVITE. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Contact: sip:9318001234567@siphost.mydomain.com. Record-Route: sip:1.1.1.1;lr=on;ftag=2F5940AC-583. User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708. Diversion: sip:10562@1.1.1.1;reason="deflection". Content-Length: 0. .

# U 1.1.1.1:5060 -> 3.3.3.3:8891 ACK sip:10562@3.3.3.3:8891 SIP/2.0. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKe22b.4c0e7b31.0. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. CSeq: 101 ACK. User-Agent: OpenSer (1.1.0-notls (i386/linux)). Content-Length: 0. .

# U 1.1.1.1:5060 -> 2.2.2.2:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. CSeq: 101 INVITE. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Contact: sip:9318001234567@siphost.mydomain.com. Record-Route: sip:1.1.1.1;lr=on;ftag=2F5940AC-583. User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708. Diversion: sip:10562@1.1.1.1;reason="deflection". Content-Length: 0. .

# U 2.2.2.2:5060 -> 1.1.1.1:5060 ACK sip:10562@1.1.1.1:5060 SIP/2.0. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. Date: Fri, 30 Mar 2007 15:29:07 GMT. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Max-Forwards: 70. CSeq: 101 ACK. Allow-Events: telephone-event. Content-Length: 0. .

# U 2.2.2.2:59105 -> 1.1.1.1:5060 INVITE sip:9318001234567@siphost.mydomain.com:5060 SIP/2.0. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A. Remote-Party-ID: <sip: 2125551212@2.2.2.2>;party=calling;screen=no;privacy=off. From: sip:2125551212@2.2.2.2;tag=2F594324-39F. To: sip:9318001234567@siphost.mydomain.com. Date: Fri, 30 Mar 2007 15:29:08 GMT. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Supported: 100rel,timer,resource-priority,replaces. Min-SE: 1800. Cisco-Guid: 1006091460-3725201883-2955804695-1520293600. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER. CSeq: 103 INVITE. Max-Forwards: 70. Timestamp: 1175268548. Contact: sip:2125551212@2.2.2.2:5060. Diversion: sip:10562@1.1.1.1;reason=deflection. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Disposition: session;handling=required. Content-Length: 268. . v=0. o=CiscoSystemsSIP-GW-UserAgent 4569 6897 IN IP4 2.2.2.2. s=SIP Call. c=IN IP4 2.2.2.2. t=0 0. m=audio 18418 RTP/AVP 0 101 19. c=IN IP4 2.2.2.2. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:19 CN/8000. a=ptime:20.

# U 1.1.1.1:5060 -> 2.2.2.2:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A. From: sip:2125551212@2.2.2.2;tag=2F594324-39F. To: sip:9318001234567@siphost.mydomain.com. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. CSeq: 103 INVITE. Server: OpenSer (1.1.0-notls (i386/linux)). Content-Length: 0. Warning: 392 1.1.1.1:5060 "Noisy feedback tells: pid=13443 req_src_ip=2.2.2.2 req_src_port=59105 in_uri=sip:9318001234567@siptest.c olumbia.edu:5060 out_uri=sip:18001234567@4.4.4.4:5060;transport=udp via_cnt==1". .

# U 1.1.1.1:5060 -> 4.4.4.4:5060 INVITE sip:18001234567@4.4.4.4:5060;transport=udp SIP/2.0. Record-Route: <sip: 1.1.1.1;lr=on;ftag=2F594324-39F;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-

.

Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKc22b.64968202.0. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A. Remote-Party-ID: <sip: 2125551212@2.2.2.2>;party=calling;screen=no;privacy=off. From: sip:2125551212@2.2.2.2;tag=2F594324-39F. Remote-Party-ID: <sip: +12125551212@siphost.mydomain.com>;party=calling;screen=no;privacy=off. To: sip:+18001234567@siphost.mydomain.com. Date: Fri, 30 Mar 2007 15:29:08 GMT. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Supported: 100rel,timer,resource-priority,replaces. Min-SE: 1800. Cisco-Guid: 1006091460-3725201883-2955804695-1520293600. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER. CSeq: 103 INVITE. Max-Forwards: 69. Timestamp: 1175268548. Contact: sip:2125551212@2.2.2.2:5060. Diversion: sip:10562@1.1.1.1;reason=deflection. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Disposition: session;handling=required. Content-Length: 268. Alert-Info: EXTERNAL. . v=0. o=CiscoSystemsSIP-GW-UserAgent 4569 6897 IN IP4 2.2.2.2. s=SIP Call. c=IN IP4 2.2.2.2. t=0 0. m=audio 18418 RTP/AVP 0 101 19. c=IN IP4 2.2.2.2. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0- # U 1.1.1.1:5060 -> 2.2.2.2:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D. From: sip:2125551212@2.2.2.2;tag=2F5940AC-583. To: sip:10562@1.1.1.1;tag=8C24D454-B4128FCF. CSeq: 101 INVITE. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Contact: sip:9318001234567@siphost.mydomain.com. Record-Route: sip:1.1.1.1;lr=on;ftag=2F5940AC-583. User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708. Diversion: sip:10562@1.1.1.1;reason="deflection". Content-Length: 0. .

# U 1.1.1.1:5060 -> 4.4.4.4:5060 INVITE sip:18001234567@4.4.4.4:5060;transport=udp SIP/2.0. Record-Route: <sip: 1.1.1.1;lr=on;ftag=2F594324-39F;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-

.

Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKc22b.64968202.0. Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A. Remote-Party-ID: <sip: 2125551212@2.2.2.2>;party=calling;screen=no;privacy=off. From: sip:2125551212@2.2.2.2;tag=2F594324-39F. Remote-Party-ID: <sip: +12125551212@siphost.mydomain.com>;party=calling;screen=no;privacy=off. To: sip:+18001234567@siphost.mydomain.com. Date: Fri, 30 Mar 2007 15:29:08 GMT. Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB@2.2.2.2. Supported: 100rel,timer,resource-priority,replaces. Min-SE: 1800. Cisco-Guid: 1006091460-3725201883-2955804695-1520293600. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER. CSeq: 103 INVITE. Max-Forwards: 69. Timestamp: 1175268548. Contact: sip:2125551212@2.2.2.2:5060. Diversion: sip:10562@1.1.1.1;reason=deflection. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Disposition: session;handling=required. Content-Length: 268. Alert-Info: EXTERNAL. . v=0. o=CiscoSystemsSIP-GW-UserAgent 4569 6897 IN IP4 2.2.2.2. s=SIP Call. c=IN IP4 2.2.2.2. t=0 0. m=audio 18418 RTP/AVP 0 101 19. c=IN IP4 2.2.2.2. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-

On Mar 30, 2007, at 9:49 AM, Bogdan-Andrei Iancu wrote:

Hi Zahid,

is the second 302 identical to the fist? is there any ACK from CISCO GW to openser as response to first 302?

regards, bogdan

zm23 wrote:

...

I made a mistake saying it was a REFER method. This is happening with just a 302 reply messages. Any suggestions?

Thanks.

On Mar 28, 2007, at 12:17 PM, zm23 wrote:

...

Hello All, I am trying to find out the proper/best way to handle REFERs coming from phone. My setup is as follows:

               Cisco gw                          

openser phone gw 2

DID 1234 -----> Invite -----------------> -------------------->

<----- 302 msg <--------------------- <--------------------302 moved....

              new #5678 sent back

After receiving new invite, openser sends it out to another gateway

5678 ----> invite ----------------------> --------------------------------------------------->

yet i am still seeing the 302 messages sent back from proxy to cisco gw.

   <------------------------------- -- 302 moved

Call does connect to 5678 but is dropped after few seconds with only one way audio.

What needs to be done so that when second invite hits proxy, there are no more 302s sent back?

Should I process the 302 in proxy itself?

What is the best way to make the 2nd call to 5678 so that it can be identified as a separate call?

Thank you in advance for your help in this regards.

--Zahid

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users