Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
On Mon, 27 Nov 2006 00:01:28 +0100 "Bent Bagger" <[EMAIL PROTECTED]> wrote: > I have uploaded the trace to Savefile.com > > http://www.savefile.com/files/293084 Thank you for taking the time to do this, because hopefully we can now move on to solving the actual problem rather than continuing the rather ridiculous discussion about how to guess the contents of an RTP packet :) The log file you provided shows the following: 0.0513 Send INVITE 0.0555 Receive 100 Trying 0.0571 Receive 200 OK 0.0603 Send ACK 0.0619 Receive first G.711 RTP packet 2.7807 Receive first H.261 RTP packet This obviously shows that Asterisk waits until receiving the ACK before send RTP. I'd be curious to know if Asterisk supports early media via 183 Session Progress - if that is enabled we should see media after the 183 but before the 200. Back to the problem at hand... My guess is that OPAL/Ekiga is not playing the audio until the first H.261 packet is received. I can't think why this would be happening - I'll need a level 4 trace log from OPAL before I can determine why this would be happening. BTW: does simpleopal do the same thing? Craig --- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
I have uploaded the trace to Savefile.com http://www.savefile.com/files/293084 Regards, Bent ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
On Sun, 26 Nov 2006 17:49:42 +0100 "Bent Bagger" <[EMAIL PROTECTED]> wrote: > Hi > > The e-mail with the trace is now awaitinh moderator approval before it > will be posted. Is there a better way of exchanging large files? The > trace is approx 1.5 MB. Please email the trace directly to me at [EMAIL PROTECTED] BTW: your last message did have a small trace (10.5k) attached to it. Is this related to the trace you are trying to send? Craig --- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] [OpenH323] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
On Mon, 27 Nov 2006 00:21:46 +0800 "Joegen E. Baclor" <[EMAIL PROTECTED]> wrote: ..deleted > > I think that this interpretation is wrong (see my previous email for why). > > > > > I agree with Damien, a offerer "MUST" be ready to accept any stream it > offered even without the the answer. > > Section 5.1, last paragraph > > Once the offerer has sent the offer, it MUST be prepared to receive > media for any recvonly streams described by that offer. It MUST be > prepared to send and receive media for any sendrecv streams in the > offer, and send media for any sendonly streams in the offer (of > course, it cannot actually send until the peer provides an answer > with the needed address and port information). We disagree on the interpretation of "prepared". "Prepared" in this context means that once an offer has been sent, it must be prepared to honor that offer. > Section 7, 3rd paragraph of RFC 3264 states: > > The offerer MAY immediately cease listening for media formats that > were listed in the initial offer, but not present in the answer. This means that once the reply has been received, it can free resources that may have been allocated as a result of the original offer. For example, an endpoint that offers both audio and video, and then receives a reply with only audio, can stop listening for video. > It is MUST and also clearly implied that the offerer should be prepared > to accept ANY payload it sent with the offer. There is no MUST in the para above. ..deleted > > The endpoint is free to chose any offered codec it wants. This may > > result in different codecs in each direction - this is OK and may be > > desirable in some cases. > > Although it is only a SHOULD in 3264, most implementations follow the > same dynamic payload type in the answer as they were mapped in the > offer. It is implied in the following section in 3264 ( Section 5.1 > Paragraph 4 ) The payload types can and do change - Asterisk is a good example of this. The fact that most endpoints don't do this is irrelevant. > For sendrecv RTP > streams, the payload type numbers indicate the value of the payload > type field the offerer expects to receive, and would prefer to send. > However, for sendonly and sendrecv streams, the answer might indicate > different payload type numbers for the same codecs, in which case, > the offerer MUST send with the payload type numbers from the answer. > > Different payload type numbers may be needed in each direction > because of interoperability concerns with H.323. I'm not sure why you think this. H.323 is the same as SIP in this regard - the called party determines whether the same or different payload types are used. > >> However, the codec to use should be determined by the RTP payload. So > >> OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the > >> correct one as soon as it receives RTP from the remote peer. > > > > I disagree that the first RTP Packet would signify the actual codec to > be used for the session. The final answer should still be considered. > During instances where the initial packet received is not equal to the > preferred codec in the answer, the offerer should honor the codec in the > answer for its outbound stream. If the offere want synchronized codec > for send and receive, then it should offer a reInvite with the single > codec preference it chooses based on the codecs it got from the answer. I disagree. You are proposing a system whereby there are potentially three different codec changes during call startup - first RTP payload detected, 183 Session Progress, and 200 OK. ..deleted Here are two references that show that RTP (even one way audio) is not established in a SIP session until the receipt of a 183 Session Progress or 200 OK. In fact, the 183 message was added specifically to allow the establishement of early media for PSTN progress tones I'm sure there are others Craig draft-ietf-music-183-00.txt - This was original source of the 183 message. There is an excellent explantion of the problem, along with very clear call flow diagrams showing the timing of RTP startup w.r.t to other SIP messages http://www3.ietf.org/proceedings/99jul/slides/mmusic-sip183-99jul/sld008.htm RFC 3666 - SIP Public Switched Telephone Network (PSTN) Call Flows -- See call flow in section 2.3 --- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting ___ ekiga-list mailing list ekiga-list@g
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
Hi The e-mail with the trace is now awaitinh moderator approval before it will be posted. Is there a better way of exchanging large files? The trace is approx 1.5 MB. Bent ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
Hi Craig On 26/11/06, Craig Southeren <[EMAIL PROTECTED]> wrote: Can someone provide me with a trace log of a call that has the "three second delay"? I'm thinking that perhaps the remote end is sending a 183 with media session information, but for some reason OPAL is not processing the media until the 200 OK is received. Here is a ethereal trace of a call from my Ekiga to my Asterisk. It has the 3 second delay in it. There are a few 'noice' frames in the trace but I hope you can use it anyway. Best regards, Bent chat-ekiga-asterisk.trace Description: Binary data ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
Craig Southeren a écrit : > On Sun, 26 Nov 2006 12:14:29 +0100 > Julien Puydt <[EMAIL PROTECTED]> wrote: > > ..deleted > >> Here is how gstreamer does, as far as I know : they get the data and >> feed it to their codecs, which return something which measures their >> confidente it is "correct data" for them. >> >> So by elimination, they get the right codec, which can then be confirmed >> and better tuned afterwards. > > This sounds like it could require a lot of resources. Eh, I didn't claim they were doing it right, just explaining how they did ;-) Can we buffer the incoming data until we know how to proceed it ? That would be a very dirty workaround, but would fly. Snark ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Ekiga video problem
Hi. Yes I think so. The first setting in 'video codec' settings: 'General settings', 'use video' is ticked. (my free translation from Finnish). -- Juha > Hi, > > Is video transmission enabled in the video codecs settings? > > Le samedi 25 novembre 2006 � 21:56 +0200, Juha Leino a �crit : >> Hello. >> >> I'm having a problem with video in [EMAIL PROTECTED] It used to work like a >> charm, but now it suddenly stopped working. The preview is ok before the >> call but as soon as call is started the video freezes. >> >> I have a Logitech UVC camera. I had problems with the driver but after I >> compiled the most recent version (split branch) it seems to be ok. My OS >> is Ubuntu Edgy with a stock kernel. >> >> One thing that came into my mind is my ADSL router (Zyxel 660HW) and its >> setup. It has NAT configured in it, and stun is in use. Zyxel also has a >> SIP ALG functionality that has been enabled (do you need stun still, or >> is >> my >> ALG dead somehow btw?). >> >> Do I perhaps need to open some ports (range of ports) for video perhaps? >> Is there any way of debugging the problem? >> >> With best regards, Juha Leino >> >> >> ___ >> ekiga-list mailing list >> ekiga-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/ekiga-list > -- > _ Damien Sandras > (o- > //\ Ekiga Softphone : http://www.ekiga.org/ > v_/_ NOVACOM : http://www.novacom.be/ > FOSDEM : http://www.fosdem.org/ > SIP Phone : sip:[EMAIL PROTECTED] > > > ___ > ekiga-list mailing list > ekiga-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list > ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] ATA or Hardware SIP Phones to use with EKIGA/VoIPBuster
Thanks Damien, I believe you probably know what I'm trying to do. I would like to do the same thing as when gnomemeeting could use the Quicknet card :) On Sat, 2006-11-25 at 17:56 +0100, Damien Sandras wrote: > Le samedi 25 novembre 2006 à 02:56 -0800, George Boyd a écrit : > > Trying to find an ATA or SIP hardware phones seems to be a daunting > > task. I love Ekiga for SIP communications and I like VOIPBUSTER for the > > price. I would like to find an ATA adapter or a SIP hardware phone that > > will work with Ekiga and/or VOIPBUSTER. > > > > I'm running Ekiga on Fedora Core 6 and connected to the internet via > > cable. Does such a device work with my setup? If so any help would be > > greatly appreciated. Of course the least cost solution would be best. > > > > I do not have any recommendation, but this page should help: > http://www.voip-info.org/wiki/view/Analog+Telephone+Adapters > ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
On Sun, 26 Nov 2006 12:14:29 +0100 Julien Puydt <[EMAIL PROTECTED]> wrote: ..deleted > Here is how gstreamer does, as far as I know : they get the data and > feed it to their codecs, which return something which measures their > confidente it is "correct data" for them. > > So by elimination, they get the right codec, which can then be confirmed > and better tuned afterwards. This sounds like it could require a lot of resources. Imagine a mobile device that has only limited CPU and supports a wide variety of audio and video codecs. Pushing every received RTP packet through every offered codec in order to find one that seems to works would require a lot of extra code to be written, and would require a lot of extra CPU. And it still doesn't address the other issues I described. I think there some other issue at work here. Can someone provide me with a trace log of a call that has the "three second delay"? I'm thinking that perhaps the remote end is sending a 183 with media session information, but for some reason OPAL is not processing the media until the 200 OK is received. But until I get a level 4 trace, I won't know for sure... Craig --- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] [OpenH323]Re: Receiving SIP RTP before media description [was ekiga answers with delay ...?]
On Sun, 26 Nov 2006 12:12:02 +0100 Damien Sandras <[EMAIL PROTECTED]> wrote: > Le dimanche 26 novembre 2006 à 12:33 +1100, Craig Southeren a écrit : > > [...] > > > If anything, it would be a bug in OPAL, and so I have copied this email > > to the correct OPAL mailing list so that other people who are > > knowledgeable in SIP may see it. > > > > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved > those I don't plan to fix to the openh323 bug tracker. Understood, and thanks. > However, I think the paragraph in the SIP RFC is clear, when you send an > offer, you must be ready to receive media for all codecs in that offer > before the offer has been acknowledged. I understand it sounds weird, > but that is one of the limitations of OPAL. I disagree. I think that this interpretation is wrong (see my previous email for why). > Another limitation is that the codec to use is determined from the 200 > OK answer in a way that is not necessarily correct. > > For example, if you send an INVITE with iLBC, PCMU and PCMA as available > codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) > back, how do you determine if you have to send iLBC or PCMU? OPAL will > send PCMU because it is the preferred codec in the answer. The endpoint is free to chose any offered codec it wants. This may result in different codecs in each direction - this is OK and may be desirable in some cases. > However, the codec to use should be determined by the RTP payload. So > OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the > correct one as soon as it receives RTP from the remote peer. No, this is not correct because the receiving endpoint can chose a differend payload type. For example, you can offer to do iLBC with payload type 108, and Speex with payload type 109. The receiver then decides do Speex with payload type 108 and starts sending RTP with payload code 108. If the offerer starts processing media when it receives the first RTP packet, it will assume it is iLBC, which is wrong. There is no way to avoid this problem other than to wait for the session parameters. See my previous email for other reasons. > However, that is a non trivial change to OPAL. It is extremely non-trivial. Robert and I cannot even see a way to do it that would not require major surgery to OPAL. > What do you think? Robert and myself discussed this this topic yesterday. Our opinion is in my previous email Craig --- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
Damien Sandras a écrit : > Le dimanche 26 novembre 2006 à 12:33 +1100, Craig Southeren a écrit : > > [...] > >> If anything, it would be a bug in OPAL, and so I have copied this email >> to the correct OPAL mailing list so that other people who are >> knowledgeable in SIP may see it. >> > > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved > those I don't plan to fix to the openh323 bug tracker. > > However, I think the paragraph in the SIP RFC is clear, when you send an > offer, you must be ready to receive media for all codecs in that offer > before the offer has been acknowledged. I understand it sounds weird, > but that is one of the limitations of OPAL. > > Another limitation is that the codec to use is determined from the 200 > OK answer in a way that is not necessarily correct. > > For example, if you send an INVITE with iLBC, PCMU and PCMA as available > codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) > back, how do you determine if you have to send iLBC or PCMU? OPAL will > send PCMU because it is the preferred codec in the answer. > > However, the codec to use should be determined by the RTP payload. So > OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the > correct one as soon as it receives RTP from the remote peer. > > However, that is a non trivial change to OPAL. > > What do you think? Here is how gstreamer does, as far as I know : they get the data and feed it to their codecs, which return something which measures their confidente it is "correct data" for them. So by elimination, they get the right codec, which can then be confirmed and better tuned afterwards. Snark ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]
Le dimanche 26 novembre 2006 à 12:33 +1100, Craig Southeren a écrit : [...] > If anything, it would be a bug in OPAL, and so I have copied this email > to the correct OPAL mailing list so that other people who are > knowledgeable in SIP may see it. > Most of the OPAL bugs are inside the Ekiga bug tracker. I have moved those I don't plan to fix to the openh323 bug tracker. However, I think the paragraph in the SIP RFC is clear, when you send an offer, you must be ready to receive media for all codecs in that offer before the offer has been acknowledged. I understand it sounds weird, but that is one of the limitations of OPAL. Another limitation is that the codec to use is determined from the 200 OK answer in a way that is not necessarily correct. For example, if you send an INVITE with iLBC, PCMU and PCMA as available codecs, and the answer comes with PCMU, PCMA and iLBC (in that order) back, how do you determine if you have to send iLBC or PCMU? OPAL will send PCMU because it is the preferred codec in the answer. However, the codec to use should be determined by the RTP payload. So OPAL should be able to send and receive PCMU/PCMA/iLBC, and choose the correct one as soon as it receives RTP from the remote peer. However, that is a non trivial change to OPAL. What do you think? -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Ekiga video problem
Hi, Is video transmission enabled in the video codecs settings? Le samedi 25 novembre 2006 à 21:56 +0200, Juha Leino a écrit : > Hello. > > I'm having a problem with video in [EMAIL PROTECTED] It used to work like a > charm, but now it suddenly stopped working. The preview is ok before the > call but as soon as call is started the video freezes. > > I have a Logitech UVC camera. I had problems with the driver but after I > compiled the most recent version (split branch) it seems to be ok. My OS > is Ubuntu Edgy with a stock kernel. > > One thing that came into my mind is my ADSL router (Zyxel 660HW) and its > setup. It has NAT configured in it, and stun is in use. Zyxel also has a > SIP ALG functionality that has been enabled (do you need stun still, or is > my > ALG dead somehow btw?). > > Do I perhaps need to open some ports (range of ports) for video perhaps? > Is there any way of debugging the problem? > > With best regards, Juha Leino > > > ___ > ekiga-list mailing list > ekiga-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
