Here's a few ideas. Possibly the remote UAS did not appreciate something in the SDP you provided.
I would be surprised if the username in the "o=" line made a difference (in my experience it usually does not). Possibly the [auto_media_port] on the "c=" line (I usually see [media_port] there, combined with "-m <media_port>" on the command line. Maybe the [local_ip_type] and/or [media_ip_type] tags were not being replaced by "4" as they should? Or otherwise possibly the only codec offered (PCMA, PT#8) was not appreciated (but there should have been a hint with a failure response to the INVITE, not a BYE). -- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.com jeannot.langl...@mitel.com "No matter how far you have gone on the wrong road, turn back." - Turkish proverb -----Original Message----- From: Julien Lamarche Sent: Friday, April 17, 2020 5:29 PM To: sipp-users@lists.sourceforge.net Subject: [Sipp-users] Unexpected BYE after ACK to INVITE with Broadworks server (fixed) FYI: In case someone has to deal with a Broadworks server I was setting up a sipp scenario to interact with with Comwave**. I noticed in their replies a hint they were probably using Broadworks: nonce="BroadWorksXk94aj1wsTz6gvvkBW" I had tested my scenario with an Asterisk server. It had worked nicely. Once we switched to interacting with Comwave / Broadworks, I hit a few roadblocks. The latest problem was that after sending an ACK to an OK message, I was getting an unexpected BYE. Having had a successful session with the Comwave account with Linphone, I wasn't giving up easily. I spent much time comparing the last message I sent, an ACK, before the unexpected BYE to no avail. What made the behavior disappear was changing the payload in the invite, a few messages back. Being new to sipp, I had copied and pasted different scenarios without paying attention. I had used, I think the UAC with media scenario. Coping the INVITE paywork from the successful linphone session seemed to do the trick. I am no expert of INVITE payload syntax at this point, so I would be curious to see what others think of the diff below. At first, I thought it might just be changing "s=-f" -> "s=Talk" and "o=user1" -> o=[$fromuser], but that did not suffice. The final diff is here: < v=0 < o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] < s=-f < c=IN IP[media_ip_type] [local_ip] < t=0 0 < m=audio [auto_media_port] RTP/AVP 8 101 < a=rtpmap:8 PCMA/8000 < a=rtpmap:101 telephone-event/8000 < a=fmtp:101 0-11,16 --- > > v=0 > o=[$fromuser] 1242 3811 IN IP4 [local_ip] > s=Talk > c=IN IP4 [local_ip] > t=0 0 > m=audio 7078 RTP/AVP 124 111 110 0 8 101 > a=rtpmap:124 opus/48000 > a=fmtp:124 useinbandfec=1; usedtx=1 > a=rtpmap:111 speex/16000 > a=fmtp:111 vbr=on > a=rtpmap:110 speex/8000 > a=fmtp:110 vbr=on > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-11 > > Julien ** Dealing with Comwave in Toronto, Canada, ICIM -- -- Make innovation easy https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.credil.org%2F&data=02%7C01%7Cjeannot.langlois%40mitel.com%7Cb4e406e2647443b19c5808d7e3167b66%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637227558021424185&sdata=uqUcCvzU9xU4QhYzU1gF4IF2SwhXzkRZDSNtZBDeHIA%3D&reserved=0 _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fsipp-users&data=02%7C01%7Cjeannot.langlois%40mitel.com%7Cb4e406e2647443b19c5808d7e3167b66%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637227558021424185&sdata=fDzwkFOADQC1TyliyGBGDXyDv%2BOdekrFVDrHDm4NZt8%3D&reserved=0 ________________________________ NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message. _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
