Hello Inaki,
Thanks very much for such a fast reply.
i have few more ques.
1) if for sending UDP msgs, i am using sendto, then I will not receive any
transport error. Thus what should I do say I am UAS
UAC UAS
Invite
------------>
2/3/4/5xx
<------------
Now I dnt receive any ACK.
should I try alternate( i guess NO) and if yes den how do I maintain my
timers.
2) 3) similarly while sending in dialog request say info, if I dnt get reply
to> info, then shud i contact alternate ip addresses?
No, when you send an in-dialog request the destination is the
remote-target (the other endpoint "Contact" header URI). That URI
contains a definitive location, i.e:
- sip:[email protected] <sip%[email protected]> -> UDP 1.2.3.4:5060
- sip:[email protected]:6666;transport=TCP -> TCP 1.2.3.4:6666
- sip:[email protected]:5082;transport=UDP -> UDP 1.2.3.4:5082
In all these cases there is not (and there cannot be) an alternative
address, since the peer you are speaking with has, usually, just one
contact address.
If the contact contains FQDN then I have to do DNS query. Its the case that
on DNS resolval, it will give me only one IPaddress.
On Tue, Mar 3, 2009 at 4:04 PM, Iñaki Baz Castillo <[email protected]> wrote:
> 2009/3/3 sarvpriya <[email protected]>:
> > hello,
> > I am currently implementing RFC 3263. My SIP application only supports
> UDP.
> > I want to know that while sending outgoing requests or responses, if it
> > fails then alternate address needs to be tried. Can you please give
> > definition of this "fails"
>
> > 1) it could be transport error ( vat kind of transport error for UDP)
>
> Yes.
>
>
> > 2) If i send an outgoing invite and i rcv no response i.e not even 1xx,
> then
> > in this sceanrio also do I need to try for alternate address?
>
> Yes, sure. Note that in case of not receiving 100, the timer expires
> in a few seconds.
>
>
> > 3) similarly while sending in dialog request say info, if I dnt get reply
> to
> > info, then shud i contact alternate ip addresses?
>
> No, when you send an in-dialog request the destination is the
> remote-target (the other endpoint "Contact" header URI). That URI
> contains a definitive location, i.e:
> - sip:[email protected] <sip%[email protected]> -> UDP 1.2.3.4:5060
> - sip:[email protected]:6666;transport=TCP -> TCP 1.2.3.4:6666
> - sip:[email protected]:5082;transport=UDP -> UDP 1.2.3.4:5082
>
> In all these cases there is not (and there cannot be) an alternative
> address, since the peer you are speaking with has, usually, just one
> contact address.
>
>
>
> To your above list you must add:
>
> 4) I receive a 503 from my proxy/pbx. In that case if you got
> destination alternatives when performing the DNS lookup, you must use
> them.
>
>
>
> --
> Iñaki Baz Castillo
> <[email protected]>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
--
cheers!!!!
sarvpriya
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
