[Sip-implementors] Register implementation

2014-04-16 Thread Aditya Kumar
Hi How is the bindingĀ developedĀ in a REGISTER?. I see in some REGISTER messages the contact is having IP address and in some there is user@domain? what should be the case?is it mandatory to have the user part? ___ Sip-implementors mailing list Sip-imple

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread isshed
Thanks Paul and everyone ... I am designing Phone1 to use only one audio and one video. Phone1 supports secured media as well. so it is offering both secure/non secure to phone2 and expects phone2 to select among the given m-lines (RTP and SRTP). Thanks. On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyz

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Paul Kyzivat
I read a number of the replies to this, but couldn't find an obvious place to jump in, so I'm just replying here. An offer multiple audio and/or video m-lines does not mean that they are *alternatives*. Absent some explicit indication, there is no way to know what the offerer's intent is in of

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Seshagiri Kondaveti
Hi I believe It depends on implementation also. The client can send reinvite with port zero for unwanted m-lines or it can send SRTP directly. We have tested RTP/AVPF and RTP/AVP with 4 m-lines ,if the answerer responds with 4 valid m-lines then we prefer RTP/AVPF and starts sending media. Our

[Sip-implementors] Regarding crypto parameters in offer/answer

2014-04-16 Thread Kashif Husain
Hello all, We have a scenario where my endpoint receives multiple crypto in the offer it selects two of them responds with them in the answer: Offer: a=crypto:1 AES_CM_256_HMAC_SHA1_32 inline:raAXCEI2rA+J7VjZo2Z906Lwa+KHSUAW407zRJYwNOSVW5o2HtrdTyI9kq7mnA==|2^31 a=crypto:2 AES_CM_256_HMAC_SHA1_80

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Brett Tate
Hi, If I recall correctly, there are MMUSIC RFCs (such as maybe RFC 6871) which can potentially be used to clearly communicate to answerer that it prefers only specific combinations of audio and video to be successfully answered. This could potentially help avoid the need for subsequent offer/ans

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Gaurav Kumar
Hi, This Offer-Answer is use-case of supporting multiple m-line for SRTP. The answerer does support SAVP (for media encryption). Ideally, Answerer should keep the port zero for audio and video m-lines with RTP/AVP and non-zero port for audio and video m-lines with RTP/SAVP (if the answerer want

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Brett Tate
> Which m line should phone1 select to send and > receive audio and video. >From an offer/answer perspective, all of the m lines. -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Katsidoniotis, Manolis (NSN - US/Irving)
I think this happens with codecs. The first one from each list would be the selected and would be initially used unless re-offer or switch on the fly tales place. However in the case of m-lines (ie. multiple negotiated streams) I'm under the impression that unless port is 0 in any of them then

Re: [Sip-implementors] SDP offer answer model

2014-04-16 Thread Mayank Kamthan
I think the first audio line and the first video line in the answer should be taken as the negotiated codecs. Thanks, Mayank. Mayank Kamthan On Wed, Apr 16, 2014 at 12:21 PM, isshed wrote: > Hi All, > > I have 1 basic query regarding ofer-answer model > > > Phone1 is sending the offer with 2