Hi all
I am facing some problem like "404 not found" while doing VoIP
call in my LAB set up
Observation & Set Up details:
*********************************
1. My VoIP Test bed is comprising of Freeware SIP server
(Brekeke 2.1.6.6.) & my VoIP enabled CPE
CPE_1
Proxy CPE_2
|
| |
| INVITE F1 |
|
|--------------------> | |
|
| INVITE F2 |
|(100 Trying) F3 |
---------------------> |
|<--------------- | |
|
| 404 NOT FOUND F4|
|<---------------
404 NOT F5 |
<---------------------------|
| ACK F6
| |
|--------------->
| ACK F7 |
Note : There is no VOIP issue has been noticed while
using the older Brekeke SIP server( version 2.0.4.1)
But after upgrading to new version Brekeke
(Version 2.1.6.6), the 404 Not Found is being noticed
Thanks in advanced for your suggestion on the above VOIP
issue
thanks & regard
tapan Kumar
On Tue, Nov 4, 2008 at 10:30 PM, <
[EMAIL PROTECTED]> wrote:
> Send Sip-implementors mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Sip-implementors digest..."
>
>
> Today's Topics:
>
> 1. Re: SIP media change - Is the precedence for c=0.0.0.0 or a=
> attribute? (Paul Kyzivat)
> 2. Re: rtpmap:18 G729a/8000 ? (Harsha. R)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 03 Nov 2008 12:59:15 -0500
> From: Paul Kyzivat <[EMAIL PROTECTED]>
> Subject: Re: [Sip-implementors] SIP media change - Is the precedence
> for c=0.0.0.0 or a= attribute?
> To: Subbu Rajendran <[EMAIL PROTECTED]>
> Cc: [email protected]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> Subbu Rajendran wrote:
> > I was trying to prove that if offer contains c=0.0.0.0 <http://0.0.0.0>
> > and any one of the a=recvonly/sendonly/sendrecv/inactive attribute then
> > the client can safely process this offer in the same manner as for hold.
>
> I don't know what you mean when you say "the client can safely process
> this offer in the same manner as for hold". I have the following
> confusion with that simple statement:
>
> - do you mean "client" or "server"? From context I think you mean server.
>
> - or do you really mean "answerer"? While the server is often the
> answerer, not always.
>
> - even if you meant both server and answerer, I don't know what you
> mean, because while the offerer can know that the intent was "hold" the
> answerer cannot ever know that.
>
> > I think I confused things with my explanation in my previous email :-)
> >
> > For the example used below, the gateway GW2 supports call hold using
> > both RFC 3261 (c=0.0.0.0 <http://0.0.0.0>) and RFC 3264 (a=inactive)
> > methods.
> >
> > Say SIP gateway GW1 sends an offer in reinvite to another gateway GW2
> > with SDP containing c=0.0.0.0 <http://0.0.0.0> and a=recvonly.
>
> I don't understand the <http://0.0.0.0> above!
>
> This informs GW2 that GW1 does support the a=<direction> attributes.
>
> It is also an odd case - its not the normal "hold", which is typically
> with a=sendonly. This is compatible with "mute", but AFAIK that is
> normally handled locally and not signaled. (Though I don't know why.)
>
> > As per
> > O/A model, GW2 can generate answer with SDP containing valid IP &
> > a=sendonly or inactive.
>
> If fact, is is required to put a compatible attribute in the response,
> regardless of the c= value.
>
> > Since GW2 can neither send any RTP/RTCP as the
> > destination media address is not known nor receive any RTP/RTCP from
> > 0.0.0.0 <http://0.0.0.0>, it would be more appropriate that the answer
> > contains a=inactive.
>
> That is a value judgment on your part. You may use a=inactive, but you
> could use sendonly if you wish. But since you can't send, it makes
> little difference.
>
> > The '0.0.0.0 <http://0.0.0.0>' is a reserved value
> > and is seldom used as a packet address, and is not normally valid. The
> > valid c= address in the answer from GW 2 serves no purpose here or does
> it?
>
> A valid c= address in the response would mean very little in this
> particular case, since GW1 wouldn't be permitted to send to it. However
> it could send you RTCP, for whatever that is worth under the circumstances.
>
> > Similarly, GW1 sends an offer in reinvite to GW2 with SDP containing
> > c=0.0.0.0 <http://0.0.0.0> and a=sendonly.
>
> This is at least compatible with a "hold".
>
> > As per O/A model GW2 can
> > generate answer with SDP containing valid IP & a=recvonly or inactive.
> > Since GW2 can neither receive any RTP/RTCP from 0.0.0.0 <http://0.0.0.0>
> > nor send any RTP/RTCP as the destination media address is not known, it
>
> The 0.0.0.0 is not necessarily the source address for media that GW1
> might send to GW2. So responding with a=recvonly is a meaningful thing
> to do.
>
> > would be appropriate that the answer contains a=inactive. Again, the
> > valid c= address in the answer from GW 2 serves no purpose here or does
> it?
>
> Again, a=inactive is a choice you can make. It might be a good choice if
> you intend to ignore any media that isn't from the media address that
> GW1 provided.
>
> So the c= can be useful for a couple of reasons. But if you prefer to
> respond with c=0 that is also acceptable.
>
> Thanks,
> Paul
>
> > If this c=address in the answer from GW2 has no purpose then it can as
> > well send c=0.0.0.0 <http://0.0.0.0>. Eventually making the answer
> > contain c=0.0.0.0 <http://0.0.0.0> and a=inactive which is nothing but
> > the answer, from a GW that supports both RFC 2543 and RFC 3264, for an
> > offer to put the call on hold.
> >
> > So I'm trying to find out if my first statement is proved to be right?
> >
> > Thanks
> > Subbu
> >
> > On Thu, Oct 30, 2008 at 8:30 AM, Paul Kyzivat <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >
> >
> > Subbu Rajendran wrote:
> >
> > Hi,
> > Thanks for your responses.
> >
> > In my opinion, there are three options to handle this Re-INVITE
> > 1. Respond to Re-INVITE with 4xx say 403 Forbidden
> > However as, Paul pointed out, reinviting with c=0 and/or
> > a=sendonly is
> > all legal.
> >
> >
> > This is very bad response.
> >
> >
> > 2. Give precedence to c=0.0.0.0 <http://0.0.0.0> over a=recvonly
> > Put the call on hold and answer SDP contains c=0.0.0.0
> > <http://0.0.0.0> and a=inactive.
> >
> >
> > I have no idea what you mean by "give precedence.
> > You can honor both, though in some ways the cases are degenerate.
> >
> > By honoring the offer with sendonly/recvonly (I forget which you
> > said it was), you assume the inverse. If that means you should
> > receive, then be prepared to do so. If it means you should send,
> > then consider you have the *option* to do so.
> >
> > But then the c=0 puts constraints on what you can do. Namely you
> > can't send, media or rtcp. But you can still receive. (Unless of
> > course you insist on symmetric RTP, in which case you will reject
> > incoming media. Unless of course it originates from 0.0.0.0
> > <http://0.0.0.0> :-)
> >
> >
> > 3. Give precedence to a=recvonly attribute
> > Since c=0.0.0.0 <http://0.0.0.0>, it is not safe to assume
> > that media could be received
> > from the last valid remote media connection address.
> >
> >
> > O/A doesn't require symmetric RTP, so its possible that legitimate
> > media is being sent from some other address. But its now common to
> > require symmetric RPT. In that case see above.
> >
> >
> > Put the media on hold
> > and send a=sendonly or a=inactive in answer. However as the
> > local media is
> > put on hold, it would make more sense to send a=inactive in the
> > answer.
> >
> >
> > Deciding to "put the local media on hold" (whatever that means) is
> > up to you. You cannot assume that the offer *means* "hold". You are
> > just doing what you do when the media flows are arranged that way.
> >
> > (What does it mean to you to put the local media on hold?)
> >
> >
> > Next, should we publish a valid IP in the c= line in the 200 OK?
> > My opinion
> > is no, because when the remote end is ready to
> > exchange/accept/send media
> > another Re-INVITE must be send to inform it's media connection
> > address to
> > the local end, then the media connection address for the local
> > end can be
> > send in the answer.
> >
> >
> > Don't make unnecessary assumptions about the other end. They are
> > likely to get you in trouble. See the offer/answer draft for
> > discussion of this. You should send an answer that best expresses
> > what your UA wants to do, constrained by what the O/A rules let you
> > answer.
> >
> > In this case, if you are willing to accept media even though the
> > other end has given you no media address, then you should probably
> > provide an address. If you are not willing to accept media, then you
> > might as well respond with inactive and you *may* give 0 as your
> > address.
> >
> > Thanks,
> > Paul
> >
> > Therefore the answer SDP in response to the Re-INVITE based on
> > points 2 &
> > 3 shall be the same as below:
> > v=0
> > o=user1 53655765 2353687637 IN IP4 192.168.1.101
> > <http://192.168.1.101>
> > s=-
> > c=IN IP4 0.0.0.0 <http://0.0.0.0>
> > t=0 0
> > m=audio 7001 RTP/AVP 0
> > a=rtpmap:0 PCMU/8000
> > a=inactive
> >
> > The above argument looks to be valid for cases where offer SDP in
> > Re-INVITE contains c=0.0.0.0 <http://0.0.0.0> and any a=
> > attribute. So, my question is can we
> > generalize that if c=0.0.0.0 <http://0.0.0.0> is present then
> > a=sendonly/recvonly/sendrecv/inactive can be ignored and be
> > processed as
> > call being put on hold?
> >
> > Thanks,
> > Subbu
> >
> > On Fri, Oct 24, 2008 at 8:26 AM, Paul Kyzivat
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > You are asking two different questions. More inline.
> >
> > Subbu Rajendran wrote:
> >
> > Hi,
> > SIP RFC 2543 uses c=0.0.0.0 <http://0.0.0.0> method to
> > put a call on hold. RFC 3264 has
> > introduced a=sendonly/recvonly/inactive/sendrecv
> > attributes that can be
> > used
> > put media to one way, hold and 2-way. However what
> > should be the
> > precedence
> > to be followed? Consider the case below
> >
> > The current recommendation for putting a call on hold is to
> > use sendonly or
> > inactive, rather than c=0. But that isn't normative
> > behavior. We haven't
> > standardized "putting on hold".
> >
> > However reinviting with c=0 and/or a=sendonly is all legal.
> > There are
> > reasons to do so that have nothing to do with hold.
> >
> > A Re-INVITE with SDP
> >
> > v=0
> > o=user1 53655765 2353687637 IN IP4 192.168.1.100
> > <http://192.168.1.100>
> > s=-
> > c=IN IP4 0.0.0.0 <http://0.0.0.0>
> > t=0 0
> > m=audio 6001 RTP/AVP 0
> > a=rtpmap:0 PCMU/8000
> > a=recvonly
> >
> > How should the SIP endpoint receiving this Re-INVITE
> > interpret the SDP,
> > w.r.t the flow of media. Which method should be given
> > preference.
> > Any help in this context is very much appreciated.
> >
> > When on the receiving side, you need to respond
> > appropriately to what has
> > been offered, taking it at face value. You cannot draw any
> > reliable
> > conclusion about the feature that led to this signaling. It
> > *might* mean you
> > have been put on hold. Or it might simply mean that the
> > offerer can't handle
> > the media right now for some other reason.
> >
> > In this case, since the IP address of the media is 0, which
> > is unusuable
> > for sending media, you definitely won't be able to send
> > media, or even RTCP.
> > Because of the a=sendonly, you still have the opportunity to
> > respond with
> > either a=recvonly or a=inactive depending on whether you
> > want to receive
> > media in this case.
> >
> > Thanks,
> > Paul
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> > <mailto:[email protected]>
> >
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 4 Nov 2008 09:30:40 +0530
> From: "Harsha. R" <[EMAIL PROTECTED]>
> Subject: Re: [Sip-implementors] rtpmap:18 G729a/8000 ?
> To: "Attila Sipos" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [email protected]
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I second Attila. Therefore if you want to use G729 Annex A encoding, do so
> using G729 in a-line of sdp, and encode using
> G729 annex A in bearer. G729 and "G729 Annex A" are inter-operable and
> there
> should be no difficulties.
>
> However you should specifically mention "annexb=no" as absence of this
> parameter implies G729 Annex B
> usage as mentioned in RFC4856 section 2.1.9
>
> " annexb: indicates that Annex B, voice activity detection, is
> used or preferred. Permissible values are "yes" and "no"
> (without the quotes); "yes" is implied if this parameter is
> omitted.
> "
>
>
> 2008/11/3 Attila Sipos <[EMAIL PROTECTED]>
>
> > no, annexb and annexa are different things:
> > annexa is a codec efficiency improvement
> > annexb is silence suppression
> >
> > In practice, I have seen usage of "rtpmap:18 G729a/8000"
> > but it has no RFC-based meaning.
> >
> > There is no way to indicate g729A. You just have to use g729.
> > The reason for lack of g729a in RFC 3550 is that g729 and g729a
> > should interoperate seemlessly - as it says...
> >
> >
> > Regards,
> >
> > Attila
> >
> >
> > Hi,
> > Please let me know if "rtpmap:18 G729a/8000" is a wrong format.
> >
> > I guess RFC3551 says it should work (page 19, as pasted below) and I am
> > not able to find anything so specific in RFC3550.
> >
> >
> >
> > Thanks & Regards
> > Viresh Gupta
> >
> >
> >
>
>
> --
> Regards
> Harsha
>
>
> ------------------------------
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> End of Sip-implementors Digest, Vol 68, Issue 4
> ***********************************************
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
