Hi I have a question regarding open source SIP proxies, I want to allow data that sits on a REST endpoint to the SIP headers as they flow through the proxy. Currently a Cisco CME is connected to a SIP trunk. Can we have a CME connect to the proxy, and the proxy to the SIP trunk. The SIP proxy doesn’t need to be production grade, but it does need to be flexible – ideally able to run code to connect to a REST endpoints and pull that into the proxy for inclusion in the SIP headers.
Thanks, Michael -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu <sip-implementors-boun...@lists.cs.columbia.edu> On Behalf Of Richard Phernambucq Sent: October 29, 2018 4:30 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Is preserving payload definitions when renegotiate media session a must? Hi Philipp, >> So the "m="line has to contain one payload value of the offer?! It has to contain a codec (format) listed in the offer, not a payload type number. The codec specifies the format of the RTP sent. Both sides need to be able to code/decode the format (e.g. PCMA) so both offer and answer must indicate the same codec. The payload type number is used in the payload type field of sent RTP packets to indicate to the receiving side which format this RTP packet's payload is in. Best regards, Richard Phernambucq On 29-10-2018 12:10, Philipp Schöning wrote: > Thanks Richard for your extensive comments, this helps a lot. > > You wrote: > >> Furthermore, it is acceptable that offerer and answerer end up using >> different payload type number for the same codec. In that case the >> number indicates the payload type field the offerer/answerer expects >> to receive (see RFC 3264 5.1 and 6.1). That means after the Re-Invite >> the session is actually still valid: both sides send PCMA RTP; the >> server fills the payload type field with value 118 and the client with value >> 8. > > But in RFC 3264, 6.1 it is stated: > >> For streams marked as sendrecv in the answer, the "m=" line MUST >> contain at least one codec the answerer is willing to both send and >> receive, from amongst those listed in the offer. > So the "m="line has to contain one payload value of the offer?! > > Best Regards > Philipp Schöning > > Am Mo., 29. Okt. 2018 um 11:34 Uhr schrieb Richard Phernambucq < > r.phernamb...@cuperus.nl>: > >> Hi Philipp, >> >>>> Is this actually possible that different payload type numbers have >>>> the same attributes? >> Yes, see the second quote from RFC 3264. >> >> You have a point when you say this is not a change of codecs, but a >> change of attributes for the same codec. This is allowed as stated in >> RFC 3264 8.3.4 (Changing attributes). But you're not making it easy >> for the answerer, especially since the new attributes have already >> been negotiated for another payload type number during the original Invite. >> To prevent interoperability issues you'd probably use payload type >> number 118 in the Re-Invite, instead of changing the attributes for >> payload type number 8. >> >> Furthermore, it is acceptable that offerer and answerer end up using >> different payload type number for the same codec. In that case the >> number indicates the payload type field the offerer/answerer expects >> to receive (see RFC 3264 5.1 and 6.1). That means after the Re-Invite >> the session is actually still valid: both sides send PCMA RTP; the >> server fills the payload type field with value 118 and the client with value >> 8. >> >> Actually, according to RFC 3264, it isn't even necessary for the >> server to send the Re-Invite. The codec in the Re-Invite offer/answer >> has already been negotiated during the original Invite offer/anwer >> and the offerer (server) is allowed switch between codecs during a >> session. This is stated in chapter 5.1: >> >> If multiple formats are listed, it >> means that the offerer is capable of making use of any of those >> formats during the session. In other words, the answerer MAY change >> formats in the middle of the session, making use of any of the >> formats listed, without sending a new offer. >> >> >> Best regards, >> Richard Phernambucq >> >> On 29-10-2018 10:14, Philipp Schöning wrote: >>> Hi Richard, >>> >>> thanks for your answer. >>> >>> I totally agree to you when you interprete this as a change of >>> payload >> type >>> number from 118 to 8. >>> But I think it is also a legitimate view, that this Re-Invite does >>> not represent a change of payload type number, but a change of the >>> attributes of payload 8. >>> >>> So in this case, parameters of codec 118 did not change, but only >>> the parameter of 8 changed. >>> Is this actually possible that different payload type numbers have >>> the >> same >>> attributes? >>> >>> >>> Best Regards >>> Philipp Schöning >>> >>> >>> Am Mo., 29. Okt. 2018 um 08:06 Uhr schrieb Richard Phernambucq < >>> r.phernamb...@cuperus.nl>: >>> >>>> Hi Philipp, >>>> >>>> According to RFC 3264 the server sending the Re-Invite is wrong. >>>> See chapter 8.3.2 (Changing of Set of Media Formats): >>>> >>>> (...) in the case of RTP, the mapping from a particular dynamic >>>> payload type >>>> number to a particular codec within that media stream MUST >>>> NOT >> change >>>> for the duration of a session. >>>> >>>> So changing the payload type number from 8 to 118 during the >>>> session is not allowed. It would have been allowed though if >>>> payload type number >>>> 118 wasn't already in use (see same chapter): >>>> >>>> (...) it is acceptable for multiple payload type numbers to be >>>> mapped to the same >>>> codec, so that an updated offer could also use payload type >>>> number >> 72 >>>> >>>> >>>> Best regards, >>>> Richard Phernambucq >>>> >>>> >>>> >>>> On 27-10-2018 14:52, Philipp Schöning wrote: >>>>> Hi all, >>>>> >>>>> we saw a SIP implementation violating the SDP offer/answer >>>>> procedure >> when >>>>> answering a Re-Invite. >>>>> >>>>> Here is the signalling: >>>>> >>>>> Server Client >>>>> >>>>> >>>>> >>>>> +----------------INVITE---------------------> >>>>> >>>>> m=audio 18410 RTP/AVP 8 100 118 >>>>> >>>>> b=AS:87 >>>>> >>>>> b=RS:1087 >>>>> >>>>> b=RR:3262 >>>>> >>>>> a=rtpmap:8 PCMA/8000 >>>>> >>>>> a=fmtp:8 vad=no >>>>> >>>>> a=rtpmap:100 telephone-event/8000 >>>>> >>>>> a=fmtp:100 0-15 >>>>> >>>>> a=rtpmap:118 PCMA/8000 >>>>> >>>>> a=gpmd:118 vbd=yes >>>>> >>>>> a=sendrecv >>>>> >>>>> >>>>> >>>>> <----------------200 OK---------------------+ >>>>> >>>>> m=audio 9158 RTP/AVP 8 118 100 >>>>> >>>>> a=rtpmap:8 PCMA/8000 >>>>> >>>>> a=fmtp:8 vad=no >>>>> >>>>> a=rtpmap:118 PCMA/8000 >>>>> >>>>> a=rtpmap:100 telephone-event/8000 >>>>> >>>>> a=fmtp:100 0-15 >>>>> >>>>> a=sendrecv >>>>> >>>>> >>>>> >>>>> +-----------------Re-Invite-----------------> >>>>> >>>>> m=audio 18410 RTP/AVP 8 >>>>> >>>>> a=rtpmap:8 PCMA/8000 >>>>> >>>>> a=gpmd:8 vbd=yes >>>>> >>>>> a=silenceSupp:off - - - - >>>>> >>>>> >>>>> >>>>> <----------------200 OK---------------------+ >>>>> >>>>> m=audio 9158 RTP/AVP 118 >>>>> >>>>> a=rtpmap:118 PCMA/8000 >>>>> >>>>> a=sendrecv >>>>> >>>>> >>>>> In the last 200OK Client is sending a Payload type (118) which was >>>>> not offered in the Re-Invite. The Re-Invite is generated when the >>>>> SIP >> Server >>>> is >>>>> detecting a fax transmission and applies ITU V.152 (Voice Band >>>>> Data), >>>> this >>>>> is also how gpmd Attribute is introduced. >>>>> >>>>> >>>>> The SIP Client vendor commented this on the case: >>>>> >>>>> *"after call is answered (media session is established), provider >>>>> renegotiates codec set and changes PCMA codec description bound to >>>> payload >>>>> 8 with the description which was bound to payload 118 in initial >>>>> negotiation of media session.* >>>>> >>>>> *It causes conflict, because new description of PCMA codec is >>>>> already >>>> bound >>>>> to payload 118 in initial offer/answer.* >>>>> >>>>> >>>>> *Voip provider can configure own side of trunk and avoid usage of >>>>> non-standard extensions in payload description (remove unnecessary >>>>> duplication of codecs). Also, provider need to preserve payload >>>> definitions >>>>> when renegotiate media session."* >>>>> >>>>> >>>>> So is the vendor right by saying that payload description have to >>>>> be preserved during a session? It did not find this in the SDP >> offer/answer >>>>> RFCs. >>>>> >>>>> We never saw any other vendor having issues with this signalling. >>>>> >>>>> >>>>> Best Regards >>>>> Philipp Schöning >>>>> _______________________________________________ >>>>> Sip-implementors mailing list >>>>> Sip-implementors@lists.cs.columbia.edu >>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> Sip-implementors@lists.cs.columbia.edu >>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
