[SIPForum-discussion] P-Access-Network-Info header for different access technologies

Fri Nov 2 10:10:11 UTC 2012

Hi All,

Please help me filling the following table for P-Access-Network-Info header
for different access technologies in a SIP header.

  P-Access-Network-Info   2G ?  EDGE ?  3G  ?  HSDPA  ?  Wi-Fi
P-Access-Network-Info:
IEEE-802.11

*Cheers* ,
Pranav Damele
*+91-9818-92-4466*

On 2 November 2012 10:25, Vijay Badola <Vijay.Badola at onmobile.com> wrote:

>  MAX-FORWARD is also not considered in responses because responses have
> to travel through VIA header field only.
>
>
>
> *,Regards*
>
> *Vijay Badola*
>
> [image: Description:
> stock-photo-young-man-looking-at-go-green-logo-42539080]
>
> *Note:We have responsibility to the environment.
> Before printing this e-mail or any other document, let's ask ourselves
> whether we need a hard copy.***
>
>
>
> *From:* Pranav Damele [mailto:pranavdamele at gmail.com]
> *Sent:* Friday, November 02, 2012 9:29 AM
> *To:* Vijay Badola
> *Cc:* Keerthi Srinivasan; sip-implementors at lists.cs.columbia.edu;
> discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] To-Tag in REGISTER message
>
>
>
> 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 <Vijay.Badola at onmobile.com> wrote:
>
> In addition to other answers given by others, loop detection is found when
> the same request comes at same sip node again without getting final answer
> (then we check whether its loop or not). The case you are talking about
> First request is already answered, so as per my understanding, in  any case
> request  will not be responded with 482 response code by the server who has
> already created final answer for earlier request (although SIP node may
> ignore the request if you try to send request with same parameter in new
> request, which will never be the case I think).
>
>
>
> *,Regards*
>
> *Vijay Badola*
>
> [image: Description:
> stock-photo-young-man-looking-at-go-green-logo-42539080]
>
> *Note:We have responsibility to the environment.
> Before printing this e-mail or any other document, let's ask ourselves
> whether we need a hard copy.*
>
>
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *Keerthi Srinivasan
> *Sent:* Tuesday, October 30, 2012 4:48 PM
> *To:* sip-implementors at lists.cs.columbia.edu; discussion at sipforum.org
> *Subject:* [SIPForum-discussion] To-Tag in REGISTER message
>
>
>
> All,
>
> When UA sends REGISTER request to the server it does not contain the
> To-Tag and Server is accepts the Registration (200 OK) will have the To-Tag.
>
> If the Refresh or Deregister does not have the To-Tag in the REGISTER
> message. Is the server will accept the Refresh or Deregister REGISTER
> message or will send 482 Loop Detected as per the RFC3261 (8.2.2.2 Merged
> Requests)
>
> Here is the RFC3261 content:
> 8.2.2.2 Merged Requests
>
>    If the request has no tag in the To header field, the UAS core MUST
>    check the request against ongoing transactions.  If the From tag,
>    Call-ID, and CSeq exactly match those associated with an ongoing
>    transaction, but the request does not match that transaction (based
>    on the matching rules in Section 17.2.3), the UAS core SHOULD
>    generate a 482 (Loop Detected) response and pass it to the server
>    transaction.
>
>       The same request has arrived at the UAS more than once, following
>       different paths, most likely due to forking.  The UAS processes
>       the first such request received and responds with a 482 (Loop
>       Detected) to the rest of them.
>
> Is the Server MUST reject or Accept the Refresh / Deregister REGISTER
> request?
>
> --
> Regards,
> Keerthi
>
>
>  ------------------------------
>
>
> DISCLAIMER: The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee. Access to this
> message by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying, or distribution of the message, or any
> action or omission taken by you in reliance on it, is prohibited and may be
> unlawful. Please immediately contact the sender if you have received this
> message in error. Further, this e-mail may contain viruses and all
> reasonable precaution to minimize the risk arising there from is taken by
> OnMobile. OnMobile is not liable for any damage sustained by you as a
> result of any virus in this e-mail. All applicable virus checks should be
> carried out by you before opening this e-mail or any attachment thereto.
> Thank you - OnMobile Global Limited.
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
>
> ------------------------------
>
> DISCLAIMER: The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee. Access to this
> message by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying, or distribution of the message, or any
> action or omission taken by you in reliance on it, is prohibited and may be
> unlawful. Please immediately contact the sender if you have received this
> message in error. Further, this e-mail may contain viruses and all
> reasonable precaution to minimize the risk arising there from is taken by
> OnMobile. OnMobile is not liable for any damage sustained by you as a
> result of any virus in this e-mail. All applicable virus checks should be
> carried out by you before opening this e-mail or any attachment thereto.
> Thank you - OnMobile Global Limited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20121102/bd4e89da/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2218 bytes
Desc: not available
URL: <http://sipforum.org/pipermail/discussion/attachments/20121102/bd4e89da/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2221 bytes
Desc: not available
URL: <http://sipforum.org/pipermail/discussion/attachments/20121102/bd4e89da/attachment-0001.jpg>