I'm using openser 1.1.x, and seeing something rather strange. We are using openser as a proxy with openser and asterisk on box A, asterisk on box B. Openser listens on ports 5060 and 5065. Asterisk listens on port 5070 on box A and 5060 on box B.
When a call arrives from PSTN, it works fine if I forward to asterisk in box B. If I forward to asterisk on box A, everything seems to be going well and then openser generates a CANCEL to the receiving phone for seemingly no good reason.
You can see from the packet below that the cancel is being generated by openser, because of the user agent.
What might cause this?
Thanks, Mark Price
U 66.129.95.24:5065 -> 71.199.89.40:16742 CANCEL sip:9043067833@71.199.89.40:16742;rinstance=f5f4de634aa6bff6;transport=udp SIP/2.0..Via: SIP/2.0/UDP 66.129.95.24:5065;branch=z9hG4bK1c31.2cb72f11.0..From: "Mark Price" sip:9046268172@66.129.95.5;tag=as11c24889..Call-ID: 1a095b0e1901cead54e8d68c63271aad@66.129.95.5..To: sip:9043067833@joinuneta.com:5065..CSeq: 102 CANCEL..User-Agen t: OpenSer (1.1.0-tls (i386/linux))..Content-Length: 0....
Well, I feel slightly foolish about the post below. The CANCEL I was seeing was perfectly sensible, as it was being sent to a second phone registered to the same username, to say "stop ringing".
However, I am still having the same problem, with no good explanation. I don't know if the problem lies with openser or asterisk. But again, it looks like this:
Works:
Box A Box B ----------------- ------------------- pstn ----------> | openser |------| | | ----------------- | | asterisk | | asterisk |<---- | | ----------------- ------------------
Broken: Box A Box B ----------------- ------------------- pstn ----------> | openser |----------->| | ----------------- | asterisk | | asterisk | | | ----------------- ------------------ To be clear, all instances of openser and asterisk are explicitly bound to public IP addresses, and there are no cases of 127.0.0.1 being used in any config files.
with openser acting as a fowarding proxy between asterisk A and asterisk B. If a pstn call coms in to openser and it forwards to asterisk A, everything works fine. If openser forwards to asterisk B (whether with a manual forward, a manual t_relay, or either forward or t_relay using the dispatcher module), the phone sends en error message, one rtp packet, and hangs up. Which is strange because it has already previously responded with a 200 ok sdp packet.
If the phone is a counterpath eyebeam, it sends 481 Call/Transaction does not exist. If the phone is a linksys spa 941, it sends Status: 400 Bad Request. This suggests to me that the problem does not lie with the phone.
Interestingly, using the spa phone as an example, the call id is the same on the 400 bad request packet as on the 200 ok sdp packet.
I can send packet logs. Or if there is any other information I can help you with.
Thank you, Mark Price
On 4/9/07, Mark Price markprice@gmail.com wrote:
I'm using openser 1.1.x, and seeing something rather strange. We are using openser as a proxy with openser and asterisk on box A, asterisk on box B. Openser listens on ports 5060 and 5065. Asterisk listens on port 5070 on box A and 5060 on box B.
When a call arrives from PSTN, it works fine if I forward to asterisk in box B. If I forward to asterisk on box A, everything seems to be going well and then openser generates a CANCEL to the receiving phone for seemingly no good reason.
You can see from the packet below that the cancel is being generated by openser, because of the user agent.
What might cause this?
Thanks, Mark Price
U 66.129.95.24:5065 -> 71.199.89.40:16742 CANCEL sip:9043067833@71.199.89.40:16742;rinstance=f5f4de634aa6bff6;transport=udp SIP/2.0..Via: SIP/2.0/UDP 66.129.95.24:5065;branch=z9hG4bK1c31.2cb72f11.0..From: "Mark Price" sip:9046268172@66.129.95.5;tag=as11c24889..Call-ID: 1a095b0e1901cead54e8d68c63271aad@66.129.95.5..To: sip:9043067833@joinuneta.com:5065..CSeq: 102 CANCEL..User-Agen t: OpenSer (1.1.0-tls (i386/linux))..Content-Length: 0....
Hi Mark,
yes, please send some trace.
regards, bogdan
Mark Price wrote:
Well, I feel slightly foolish about the post below. The CANCEL I was seeing was perfectly sensible, as it was being sent to a second phone registered to the same username, to say "stop ringing".
However, I am still having the same problem, with no good explanation. I don't know if the problem lies with openser or asterisk. But again, it looks like this:
Works:
Box A Box B ----------------- -------------------pstn ----------> | openser |------| | | ----------------- | | asterisk | | asterisk |<---- | | ----------------- ------------------
Broken: Box A Box B ----------------- ------------------- pstn ----------> | openser |----------->| | ----------------- | asterisk | | asterisk | | | ----------------- ------------------ To be clear, all instances of openser and asterisk are explicitly bound to public IP addresses, and there are no cases of 127.0.0.1 being used in any config files.
with openser acting as a fowarding proxy between asterisk A and asterisk B. If a pstn call coms in to openser and it forwards to asterisk A, everything works fine. If openser forwards to asterisk B (whether with a manual forward, a manual t_relay, or either forward or t_relay using the dispatcher module), the phone sends en error message, one rtp packet, and hangs up. Which is strange because it has already previously responded with a 200 ok sdp packet.
If the phone is a counterpath eyebeam, it sends 481 Call/Transaction does not exist. If the phone is a linksys spa 941, it sends Status: 400 Bad Request. This suggests to me that the problem does not lie with the phone.
Interestingly, using the spa phone as an example, the call id is the same on the 400 bad request packet as on the 200 ok sdp packet.
I can send packet logs. Or if there is any other information I can help you with.
Thank you, Mark Price
On 4/9/07, Mark Price markprice@gmail.com wrote:
I'm using openser 1.1.x, and seeing something rather strange. We are using openser as a proxy with openser and asterisk on box A, asterisk on box B. Openser listens on ports 5060 and 5065. Asterisk listens on port 5070 on box A and 5060 on box B.
When a call arrives from PSTN, it works fine if I forward to asterisk in box B. If I forward to asterisk on box A, everything seems to be going well and then openser generates a CANCEL to the receiving phone for seemingly no good reason.
You can see from the packet below that the cancel is being generated by openser, because of the user agent.
What might cause this?
Thanks, Mark Price
U 66.129.95.24:5065 -> 71.199.89.40:16742 CANCEL sip:9043067833@71.199.89.40:16742;rinstance=f5f4de634aa6bff6;transport=udp
SIP/2.0..Via: SIP/2.0/UDP 66.129.95.24:5065;branch=z9hG4bK1c31.2cb72f11.0..From: "Mark Price" sip:9046268172@66.129.95.5;tag=as11c24889..Call-ID: 1a095b0e1901cead54e8d68c63271aad@66.129.95.5..To: sip:9043067833@joinuneta.com:5065..CSeq: 102 CANCEL..User-Agen t: OpenSer (1.1.0-tls (i386/linux))..Content-Length: 0....
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Ok, third try. Previous messages have been blocked for too much text. This is an ngrep log attached (i have pcap if you want, but it was blocked by the mail server). destination number is 9043067833. The softphone is 66.129.95.30 The sip proxy is 66.129.95.24 Asterisk is 66.129.95.5.
On 4/11/07, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Mark,
yes, please send some trace.
regards, bogdan
Hi Mark,
I would say the problem is with the UAS (NETA Phone release 1009u stamp 39129) - I see it accepts the call, sends 200 OK and than sends 400 Bad request.
first it should not send another final response after 200 and secondly it should not use 400 if it is not parse/format error (which it doesn't seams to).
my guess is this has something to do with the fact that the 200 ACK does not get to this UAS - the trace shows the ACK only from UAC to proxy. Maybe the missing ACK triggers this bogus reaction of 400 reply.
try to fix the ACK problem and report the error to the device manufacture.
regards, bogdan
Mark Price wrote:
Ok, third try. Previous messages have been blocked for too much text. This is an ngrep log attached (i have pcap if you want, but it was blocked by the mail server). destination number is 9043067833. The softphone is 66.129.95.30 The sip proxy is 66.129.95.24 Asterisk is 66.129.95.5.
On 4/11/07, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Mark,
yes, please send some trace.
regards, bogdan
-
Bogdan-Andrei Iancu -
Mark Price