Re: [Sip-implementors] Redirection of Call without REFER

2015-10-11 Thread Pranav Damele
Hey Mayank, What if you use 3xx—Redirection Responses for that matter? i.e. 301/302 Regards, Pranav Damele Senior Software Engineer *Mobile:* +91-956-12-21112 *Email:* pranavdam...@gmail.com *IM:* pranavdamele (Skype) *http://in.linkedin.com/in/pranavdamele <http://in.linkedin.com

Re: [Sip-implementors] c= line for disabled media streams

2014-10-22 Thread Pranav Damele
I guess that would make subsequent answer a problem because of session level c line 0.0.0.0 ... stream level is good enough. Regards Pranav On 22 Oct 2014 22:08, "Paul Kyzivat" wrote: > On 10/22/14 11:37 AM, Saúl Ibarra Corretgé wrote: > >> Hi all, >> >> I recently ran into an intro issue with

Re: [Sip-implementors] c= line for disabled media streams

2014-10-22 Thread Pranav Damele
If its not mentioned then logic will be left for user to implement Regards Pranav On 22 Oct 2014 21:30, "Balint Menyhart" wrote: > Hi, > > RFC 4566, just where c= lines are defined: > > 5.7. Connection Data ("c=") > > c= > >The "c=" field contains connection data. > >A session de

Re: [Sip-implementors] Wrong P-Asserted Identity in Subscribe Message to CSCF

2014-07-21 Thread Pranav Damele
Hey Sunil, It will remove the incoming PAID header and then will insert PAID header based on AOR match. I think it will do regardless the incoming PAID is correct or not (according to PUI in 200 OK received at the time of UE's Registration). Regards, Pranav Damele Associate Consu

Re: [Sip-implementors] hi

2014-07-16 Thread Pranav Damele
Please find my answers inline below. Regards, Pranav Damele Associate Consultant - Engineering, Product Engineering and Development *Mobile:* +91-9818-92-4466 *Email:* pranavdam...@gmail.com *IM:* pranavdamele (Skype) *http://in.linkedin.com/in/pranavdamele <http://in.linkedin.com

Re: [Sip-implementors] hi

2014-07-16 Thread Pranav Damele
Call will continue until expiry is reached. If ep re-registers well and fine else call is terminated. Regards, Pranav Damele Associate Consultant - Engineering, Product Engineering and Development *Mobile:* +91-9818-92-4466 *Email:* pranavdam...@gmail.com *IM:* pranavdamele (Skype) *http

Re: [Sip-implementors] hi

2014-07-16 Thread Pranav Damele
xy. invite goes via ep to realm to proxy mirror ep sends register to realm's ip with realm's uri. Realm registers ep to proxy. invite goes via ep to realm to proxy surrogate ep does not send register to realm. Realm on behalf of ep sends register to proxy. invite goes via ep to realm

Re: [Sip-implementors] hi

2014-07-16 Thread Pranav Damele
ld have to do like call forwarding, forking etc. considering that you don't have to manage it on your proxy. Regards, Pranav Damele Associate Consultant - Engineering, Product Engineering and Development *Mobile:* +91-9818-92-4466 *Email:* pranavdam...@gmail.com *IM:* pranavdamele (Skype)

Re: [Sip-implementors] hi

2014-07-15 Thread Pranav Damele
implemented in a session border controller. Regards, Pranav Damele Associate Consultant - Engineering, Product Engineering and Development *Mobile:* +91-9818-92-4466 *Email:* pranavdam...@gmail.com *IM:* pranavdamele (Skype) *http://in.linkedin.com/in/pranavdamele <http://in.linkedin.com/in/p

Re: [Sip-implementors] [SIPForum-discussion] To-Tag in REGISTER message

2012-11-01 Thread Pranav Damele
Hi , I second to Vijay. That is why Max-Forwards header is not required in responses. *Cheers* , Pranav Damele On 1 November 2012 10:26, Vijay Badola wrote: > In addition to other answers given by others, loop detection is found > when the same request comes at same sip node again w

Re: [Sip-implementors] 401 Unauthorized message!

2011-03-22 Thread Pranav Damele
Hi Siga, Could you show your INVITE and 401 Unauthorized messages. *Cheers* [?], Pranav Damele *+41-766-099-288* On 22 March 2011 14:12, wrote: > Send Sip-implementors mailing list submissions to >sip-implementors@lists.cs.columbia.edu > > To subscribe or unsubscribe v

Re: [Sip-implementors] Audio Port problem (Pranav)

2011-03-09 Thread Pranav Damele
>port number (source port) from which I send my RTP works perfectly fine. > >if you say this is absolutely fine then I really don't need to worry. The >only thing I need to take care is that I should use my own defined RTP port >(which I have sent with my INVITE/SDP) to listen to incomi