[Sip-implementors] Serach order for multiple Diversion headers

Hi If a request contains multiple Diversion headers, can one assume that the topmost is used, or is this up to the application? I'm looking for a MUST in one of the RFCs. Cheers /Roger ___ Sip-implementors mailing list Sip-implementors@lists.cs.columb

[Sip-implementors] SIPREC and call transfer without REFER

Hi list! We are testing out SIPREC in our Acme SBCs. The goal is to be "PBX neutral" for a lack of a better word. We are using Verba as SRS. Basic incoming and outgoing calls work fine. SRC sends SIPREC INVITE to SRS with metadata containing A och B parties. Now, 100% of our customers that want

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

I agree with you but Nokia does not. Basically what they are saying is this: If SDP version number is incremented then this counts as an update/new offer period. The problem is I can't find an RFC stating "You MUST NOT increment version number if no change is made to the SDP" Even Paul Kyzviat i

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

e response for the same INVITE transaction." The only thing left to interpretation IMO is if version increment with no SDP change is considered an update. Thoughts on this? /Roger On Thu, Sep 17, 2015 at 10:06 PM, Roger Wiklund wrote: > Thanks, makes sense! > > On Thu, Sep 17

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

uot;MUST ignore". However for interoperability reasons, the > UAS can change their behavior. If I remember correctly, RFC 6337 might even > recommend not including an SDP in that situation. > > >> -Original Message- >> From: Roger Wiklund [mailto:roger.wikl...@gmail.com] >

Re: [Sip-implementors] SDP version increment without SDP change in early dialog

irst session description > it receives as the answer, and MUST ignore any session descriptions in > subsequent responses to the initial INVITE." > > More inline. > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >&g

[Sip-implementors] SDP version increment without SDP change in early dialog

Hi list I'm seeing the following behavior from an Aastra 400 PBX. Flow below is ITSP to PBX INVITE> <100Trying <183 w/SDP PRACK> <200OK (PRACK) <180 w/SDP >PRACK <200OK (PRACK) <200OK (INVITE)w/SDP ACK> BYE> <200OK (BYE) Each time the PBX sends an SDP, the version number is incremented even tho

Re: [Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

mbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger Wiklund >> Sent: Thursday, June 11, 2015 10:38 AM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] 183 with 100rel required, followed by > 180 >> wi

Re: [Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

; -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger > Wiklund > Sent: June-11-15 10:38 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] 183 with

Re: [Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger > Wiklund > Sent: June-11-15 10:34 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] 183 with 100rel required, followed by 180 > with 100rel

Re: [Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

INVITE and both PRACKs. > > Joel Gerber > Network Operations Specialist - Telephone > Telephone > Eastlink > joel.ger...@corp.eastlink.caT: 519.786.1241 > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implemento

Re: [Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

only has 100rel supported with no RSeq. Why would the PBX suddenly want to decide when to PRACK if it did not send the 100rel required in the initial INVITE? On Thu, Jun 11, 2015 at 3:58 PM, Roger Wiklund wrote: > Call flow - outgoing call from PBX to ITSP. > > --> INVITE with

[Sip-implementors] 183 with 100rel required, followed by 180 with 100rel supported

Call flow - outgoing call from PBX to ITSP. --> INVITE with 100rel supported <-- 100 trying <-- 183 session progress with 100rel required --> PRACK <-- 200 OK on PRACK <-- 180 ringing with 100rel supported --> PRACK <-- 481 Call leg/transaction does not exist I've checked the To/From tags

Re: [Sip-implementors] Q regarding call transfer and P-Asserted-Identity

gt; >> Cisco PBX behavior seems correct here .Also after transfer is complete in >> step 3 , >> Phone-A is out of picture after having BYE exchange with Phone-B and PBX. >> So during step 4, PBX should use PAI of Phone-B. >> >> Regards >> Ankur B

[Sip-implementors] Q regarding call transfer and P-Asserted-Identity

Hi folks! Scenario: ITSP--PBX--PHONE-A--PHONE-B 1. Call from PSTN via ITSP to PHONE-A (via B2BUA PBX) 2. PHONE-A answers the call 3. PHONE-A makes a supervised transfer to PHONE-B (REFER within the PBX) 4. PBX sends UPDATE/Re-INVITE to ITSP with updated SDP co