Greetings,
I'm new to this list so I don't know whether this should be here or on the developer's list.
I've been running a test and come across a problem. I have three phones and the SER proxy. Two of the phones are softphones, the third is an ATA. The ATA is at 192.168.1.3, and the two softphones are at 192.168.1.4 and 192.168.1.5. SER is at 192.168.1.7.
In the test, 192.168.1.3 and 192.168.1.4 register with the SER as AOR '100'. 192.168.1.5 then make a call to sip:100@192.168.1.7. The INVITE is forked properly however there is some strange behavior with the ACK handling. It appears that no matter which of the phones answers, the ACK is always sent to the first phone to have registered for the AOR, whether that was the phone that answers or not.
I have included an Ethereal trace file that illustrates this behavior. If you graph the VoIP call you can clearly see this situation occuring. You should be able to load this file directly into Ethereal.
I would be interested in anyones thoughts on whether this is a bug or not in SER or something else.
Thanks, FM
Frank,
If you are calling from 192.168.1.5 why do both the To and From fields in the initial INVITE show sip:100@192.168.1.7?
Leo P.
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Frank W. Miller Sent: Tuesday, May 16, 2006 10:56 PM To: serusers@lists.iptel.org Subject: [Serusers] Forking problem
Greetings,
I'm new to this list so I don't know whether this should be here or on the developer's list.
I've been running a test and come across a problem. I have three phones and the SER proxy. Two of the phones are softphones, the third is an ATA. The ATA is at 192.168.1.3, and the two softphones are at 192.168.1.4 and 192.168.1.5. SER is at 192.168.1.7.
In the test, 192.168.1.3 and 192.168.1.4 register with the SER as AOR '100'. 192.168.1.5 then make a call to sip:100@192.168.1.7. The INVITE is forked properly however there is some strange behavior with the ACK handling. It appears that no matter which of the phones answers, the ACK is always sent to the first phone to have registered for the AOR, whether that was the phone that answers or not.
I have included an Ethereal trace file that illustrates this behavior. If you graph the VoIP call you can clearly see this situation occuring. You should be able to load this file directly into Ethereal.
I would be interested in anyones thoughts on whether this is a bug or not in SER or something else.
Thanks, FM
Because the call is supposed to be coming from the AOR associated with the Service Provider that SER is representing? From 3261:
8.1.1.3 From
The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record.
The Contact header has the actual UA address in it.
Thanks, FM
On Tue, 2006-05-16 at 23:08 -0400, Leo wrote:
Frank,
If you are calling from 192.168.1.5 why do both the To and From fields in the initial INVITE show sip:100@192.168.1.7?
Leo P.
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Frank W. Miller Sent: Tuesday, May 16, 2006 10:56 PM To: serusers@lists.iptel.org Subject: [Serusers] Forking problem
Greetings,
I'm new to this list so I don't know whether this should be here or on the developer's list.
I've been running a test and come across a problem. I have three phones and the SER proxy. Two of the phones are softphones, the third is an ATA. The ATA is at 192.168.1.3, and the two softphones are at 192.168.1.4 and 192.168.1.5. SER is at 192.168.1.7.
In the test, 192.168.1.3 and 192.168.1.4 register with the SER as AOR '100'. 192.168.1.5 then make a call to sip:100@192.168.1.7. The INVITE is forked properly however there is some strange behavior with the ACK handling. It appears that no matter which of the phones answers, the ACK is always sent to the first phone to have registered for the AOR, whether that was the phone that answers or not.
I have included an Ethereal trace file that illustrates this behavior. If you graph the VoIP call you can clearly see this situation occuring. You should be able to load this file directly into Ethereal.
I would be interested in anyones thoughts on whether this is a bug or not in SER or something else.
Thanks, FM
-
Frank W. Miller -
Leo