You guys are correct. I forgot that this particular application
modifies the call signaling path to another device by updating the
contact header. It's going to add aditional complexity to account for
this in SIPp. I think I'll just tell my script to expect a "481" if I
am contacting this particular device type.
Thanks for the quick response,
--
Adam
On 4/12/2017 9:21 AM, Dale R. Worley wrote:
Brett Tate <br...@broadsoft.com> writes:
I've been scratching my head all day comparing branch branches, tags,
and call-ID's and I can't seem to pinpoint it.
Does anyone have any suggestion what I (or SIPp) might be doing wrong?
The request-uri within the ACK and BYE were not updated to reflect 2xx's
Contact sip-uri. However, I'm not sure if that was truly why the BYE was
rejected with a 481.
I'll echo Brett here, it looks like the target URI on the BYE is
incorrect and the UAS is within its rights to not recognize what dialog
the BYE is within. RFC 3261 section 12.1.2 says "The remote target MUST
be set to the URI from the Contact header field of the response."
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
