Re: [Sip-implementors] Commercial sip stack

PJSIP has two license: *The SOFTWARE* is released under dual license, open source (GPL) or alternativelicense. Is that particular lib are GPL and other lib have alternative license. I couldn't get it. I need only SIP s

Re: [Sip-implementors] Commercial sip stack

Regarding PJSIP :its available even in GPL right ? Please clarify. On Thu, Feb 4, 2010 at 2:59 AM, Joel Dodson wrote: > I'm using PJSIP (http://www.pjsip.org/) for a signaling and media > gateway and it's working very well. I use the lower layer APIs for > more control of the SIP messaging. T

[Sip-implementors] sip stack

Regarding SIP Open Source: Can i take Sip stack alone (chan_sip.c and chan_local.c) from asterisk for sip stack implementation. Actually iam trying to integrate SIP stack on a chip, maximum user allowed is 120. I appreciate any other open source suggestion also. On Thu, Feb 4, 2010 at 2:59

Re: [Sip-implementors] What is wrong with the following INVITE???

Hi, I think this is the catch. The rtpmap defines the encoding used for codec "8", but mistakenly you have used "101". Regards Sunil Verma -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Pavesi,

Re: [Sip-implementors] What is wrong with the following INVITE???

Hi, As the transport used is UDP hence I think we can use same port for both signalling and audio. Regards Sunil Verma -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Pavesi, Valdemar (NSN - US/

Re: [Sip-implementors] What is worong with that sip message???

Hi , I don't think anything is wrong with your SDP. But I think the problem is at the far end or you need to check what is received in answer. If far end has answered with media attributes "inactive" then you will not be listening any media. Also make sure that you have audio sink listening on t

Re: [Sip-implementors] Commercial sip stack

I'm using PJSIP (http://www.pjsip.org/) for a signaling and media gateway and it's working very well. I use the lower layer APIs for more control of the SIP messaging. The alternate license is reasonable and support is very good. I've also used Data Connection (http://www.metaswitch.com/) in the

Re: [Sip-implementors] What is worong with that sip message???

El Miércoles, 3 de Febrero de 2010, Franz Edler escribió: > > Sure. For example the outbound-draft (now RFC ) statesthat the > > outbound > > proxy listens in UDP port 5060 for SIP and STUN protocols. > > Yes, of course. You can design any protocol to do everything via one port. > But I had th

Re: [Sip-implementors] What is worong with that sip message???

> Sure. For example the outbound-draft (now RFC ) statesthat the > outbound > proxy listens in UDP port 5060 for SIP and STUN protocols. Yes, of course. You can design any protocol to do everything via one port. But I had the impression that with Nahum that is not the case. If you use a legacy

Re: [Sip-implementors] What is worong with that sip message???

El Miércoles, 3 de Febrero de 2010, Pavesi, Valdemar (NSN - US/Boca Raton) escribió: > it totally dependent of the application, the application can receive SIP > and send to SIP-STACK , or RTP-STEAM and sent to media-harware. Sure. For example the outbound-draft (now RFC ) statesthat the outb

Re: [Sip-implementors] What is worong with that sip message???

it totally dependent of the application, the application can receive SIP and send to SIP-STACK , or RTP-STEAM and sent to media-harware. -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Fran

Re: [Sip-implementors] What is wrong with the following INVITE???

Nahum, it a=rtpmap:101 PCMA/8000 is wrong , you must set to AVP=8 --> a=rtpmap:8 PCMA/8000 INVITE sip:+972547864...@gw1.man1.theiptele.com SIP/2.0 Via: SIP/2.0/UDP 89.139.126.116:10313;rport;branch=z9hG4bkoeyj2axhv4z3c4zanbrhl5t5808egte js Max-Forwards: 70 From: sip:0001001103...@gw1.ma

Re: [Sip-implementors] What is worong with that sip message???

This cannot work. Either a signalling process is listening to this port or a media rendering proicess but never both. Ranz _ From: Nahum Nir [mailto:hello.shalom...@gmail.com] Sent: Wednesday, February 03, 2010 6:00 PM To: Franz Edler Subject: Re: [Sip-implementors] What is woron

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

El Miércoles, 3 de Febrero de 2010, Olle E. Johansson escribió: > > However I've found a case in which this mechanism is needed: > > > > - alice sends MESSAGE to bob through the proxy. > > - the proxy replies 100 to alice and routes the MESSAGE to bob. > > - bob replies 200. > > - the proxy replie

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

3 feb 2010 kl. 19.32 skrev Iñaki Baz Castillo: > El Miércoles, 3 de Febrero de 2010, Pranab Bohra escribió: >> Picked up from rfc 3261 section 17.1: >> >> "The INVITE transaction is different from those of other methods >> because of its extended duration. Normally, >> human input is required in

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

El Miércoles, 3 de Febrero de 2010, Pranab Bohra escribió: > Picked up from rfc 3261 section 17.1: > > "The INVITE transaction is different from those of other methods > because of its extended duration. Normally, > human input is required in order to respond to an INVITE. The long > delays expect

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

Picked up from rfc 3261 section 17.1: "The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other

Re: [Sip-implementors] Why should be a non-INVITE request retransmitted after receiving a 1XX response?

Not completely sure that I understand your question. However the main difference in behavior between INVITE and non-INVITE relates to INVITE having an ACK for 3-way handshake. Since potentially relevant, you also might want to glance at RFC 4320. > -Original Message- > From: sip-implem

Re: [Sip-implementors] Why should be a non-INVITE request r etransmited after receiving a 1XX response?

El Miércoles, 3 de Febrero de 2010, Brett Tate escribió: > > "Procedding" state means that a 1XX response has been > > received so for sure we know that the proxy has received > > the request. Why then should it be retransmited after > > timer E expires? > > Some transports are not reliable. Thus

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

El Miércoles, 3 de Febrero de 2010, Pranab Bohra escribió: > Hi Inaki, > > In addition to what Brett mentioned, the 1xx response includes "100 > Trying" as well. > 100 is a hop-by-hop response and not end-to-end. So, even if the > client transaction has entered "Proceeding" state after receiving 1

Re: [Sip-implementors] Commercial sip stack

you can look into Radvision as well. On Wed, Feb 3, 2010 at 11:40 AM, Badri wrote: > Aricent SIP stack. > > > > > From: Premalatha Kuppan > To: sip-implementors@lists.cs.columbia.edu > Sent: Wed, February 3, 2010 5:21:12 PM > Subject: [Sip-implementors] Commer

Re: [Sip-implementors] Commercial sip stack

Aricent SIP stack. From: Premalatha Kuppan To: sip-implementors@lists.cs.columbia.edu Sent: Wed, February 3, 2010 5:21:12 PM Subject: [Sip-implementors] Commercial sip stack Hi, Can ny1 suggest me avery good commercial SIP STACK ? Which be portable, gud main

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

Hi Inaki, In addition to what Brett mentioned, the 1xx response includes "100 Trying" as well. 100 is a hop-by-hop response and not end-to-end. So, even if the client transaction has entered "Proceeding" state after receiving 100 from proxy, it doesn't mean that the UAS has received the request. H

Re: [Sip-implementors] What is wrong with the following INVITE???

Hi, But it should not be the problem , the endpoint-b don't nothing about the same port for sip/rtp. You must see a RTP-stream coming to your device. (endpoint-a) Regards! Valdemar -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun

Re: [Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

> "Procedding" state means that a 1XX response has been > received so for sure we know that the proxy has received > the request. Why then should it be retransmited after > timer E expires? Some transports are not reliable. Thus UAC has to resend request so the UAS will resend the final respo

Re: [Sip-implementors] What is wrong with the following INVITE???

Hi, You are using port 44074 for both SIP signalling and RTP, generally media and signalling are handled on different ports. Cheers, Pranab On Wed, Feb 3, 2010 at 3:15 PM, Nahum Nir wrote: > Hi All, > > I'm trying to make an INVITE so that the incoming audio will be received on > 89.139.126.116

[Sip-implementors] Why should be a non-INVITE request retransmited after receiving a 1XX response?

Hi, extracted from RFC 3261 page 131 for "Non-INVITE Client Transaction": If Timer E fires while in the "Proceeding" state, the request MUST be passed to the transport layer for retransmission, and Timer E MUST be reset with a value of T2 seconds. "Procedding" state means that a 1XX res

[Sip-implementors] What is wrong with the following INVITE???

Hi All, I'm trying to make an INVITE so that the incoming audio will be received on 89.139.126.116:44074. I get Session In Progress and OK but no incoming audio. What is wrong??? Thanks, Nahum INVITE sip:+972547864...@gw1.man1.theiptele.comSIP/2.0 Via: SIP/2.0/UDP 89.139.126.116:44074 ;rport;b

[Sip-implementors] Media Attribute SDP Response

Hello, I would like to know if it is mandatory to have in the SDP of the SIP response (183 or 200 OK) a corresponding media attributes ( "a=" lines) for the ones offered in the INVITE messages. I have checked the related RFC's (2327 & 3264) but I couldn't come up with a clear understanding of

Re: [Sip-implementors] What is worong with that sip message???

> I'm trying to make an INVITE so that the incoming audio will be received on > 89.139.126.116:44074. Are you sure that you selected the right port for media? From the Via header field I see that the port 44074 is already occupied by signalling. That's very strange. > Via: SIP/2.0/UDP 89.139.1

Re: [Sip-implementors] What is worong with that sip message???

Nhahm, Where is the 183 Session In Progress with SDP ? Regards! Valdemar -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Nahum Nir Sent: Wednesday, February 03, 2010 9:08 AM To: sip-implemen

[Sip-implementors] What is worong with that sip message???

Hi All, I'm trying to make an INVITE so that the incoming audio will be received on 89.139.126.116:44074. I get Session In Progress and OK but no incoming audio. What is wrong??? Thanks, Nahum INVITE sip:+972547864...@gw1.man1.theiptele.comSIP/2.0 Via: SIP/2.0/UDP 89.139.126.116:44074 ;rport;b

Re: [Sip-implementors] Commercial sip stack

El Miércoles, 3 de Febrero de 2010, Premalatha Kuppan escribió: > Hi, > > Can ny1 suggest me avery good commercial SIP STACK ? > > Which be portable, gud maintainability, small footprint and Code in C. If it's for a UA then PJsip (offers a commercial license) could be a good choice. Of course t

[Sip-implementors] Commercial sip stack

Hi, Can ny1 suggest me avery good commercial SIP STACK ? Which be portable, gud maintainability, small footprint and Code in C. Thanks, Premalatha ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cu

[Sip-implementors] Caller Preference for SIP

Hello, I'm trying to provide a service to user with multiple contacts based on the RFC3841 "Caller Preference for SIP". I read this document but I'm not quite sure if it is possible to add new features different from the ones describe in the RFC3840. If it is, will the proxies, based on this model,

Re: [Sip-implementors] Auto-Answer for Incoming call

El Miércoles, 3 de Febrero de 2010, Iñaki Baz Castillo escribió: > El Miércoles, 3 de Febrero de 2010, SungWoo Lee escribió: > > Dear, > > > > Thanks for the resposes. > > > > By the way, I have a question about Call-Info header usage. > > According to RFC3261, we see the angle-bracketed uri should

Re: [Sip-implementors] Auto-Answer for Incoming call

El Miércoles, 3 de Febrero de 2010, SungWoo Lee escribió: > Dear, > > Thanks for the resposes. > > By the way, I have a question about Call-Info header usage. > According to RFC3261, we see the angle-bracketed uri should be placed at > the right side of HCOLON. However, as Andrew mentioned, I se