Re: [Sip-implementors] Sip From header without user part

[Rakesh]

Hi Paul,

Thank you very much, I got your point.

BR///Rakesh

On Thu, Aug 4, 2022 at 10:28 PM Paul Kyzivat  wrote:

> On 8/4/22 11:09 AM, Rakesh wrote:
> > Hi Paul,
> >
> > Thanks for your response.
> > Quoting your statement "But it makes no sense to send this unless there
> > was a matching prior sip request with the same sip URI."
> >
> > If I understood correctly the earlier request prior to CANCEL is
> > normally a sip INVITE. And in case of INVITE has been sent with the such
> > format in FROM header then further requests like CANCEL can send it else
> > not.
> >
> > Do we have any reference on RFC that any SIP entity should not send sip
> >  From header as like on CANCEL if INVITE has not sent with that way?
>
> Spend some time understanding section 9 of RFC 3261.
>
> It doesn't say it is incorrect to send a CANCEL without a prior matching
> request. But it specifies what the receiver of the CANCEL should do -
> that it should send a 481 response.
>
>  From what little you have said about the situation it sounds like this
> may have been sent as part of a test. If so the sender may intentionally
> be generating error cases to see if your implementation responds to them
> as it should.
>
> Thanks,
> Paul
>
> > BR///Rakesh
> >
> > On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat  > > wrote:
> >
> > On 8/4/22 8:11 AM, Rakesh wrote:
> >  > Hi Team,
> >  >
> >  > I could see in a sip CANCEL message From Header as below
> >  >
> >  > From: "test"  > >;tag=3bbb9483d215d830c635372f8f181929
> >  >
> >  > is this correct?
> >
> > Just looking at this, without regard for context, it is valid syntax.
> > (The userinfo portion of the sip URI is optional.)
> >
> > But it makes no sense to send this unless there was a matching prior
> > sip
> > request with the same sip URI.
> >
> > Each domain is free to define the userinfo portion of its sip URIs
> > as it
> > sees fit. This includes whether to support URIs with no userinfo. You
> > might want to consult an administrator for ims.test.in
> > .
> >
> >  Thanks,
> >  Paul
> >
> >  > Normally the From header is sip:user@domain
> >  >
> >  > As per ABNF grammar, the above one is also should not be an issue
> > as From
> >  > header but could let me know if I misinterpreted the ABNF grammar?
> >  >
> >  > BR///Rakesh
> >  > ___
> >  > Sip-implementors mailing list
> >  > Sip-implementors@lists.cs.columbia.edu
> > 
> >  > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > 
> >
> > ___
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > 
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > 
> >
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip From header without user part

[Dale R. Worley]

Rakesh  writes:
> I could see in a sip CANCEL message From Header as below
>
> From: "test" ;tag=3bbb9483d215d830c635372f8f181929
>
> is this correct?

To summarize what Paul has said:  Syntactically, this header is valid.
But usually the question is whether the entire SIP message containing
the header is valid, and that often depends on the context of all the
SIP messages which have come before.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip From header without user part

[Paul Kyzivat]

On 8/4/22 11:09 AM, Rakesh wrote:

Hi Paul,

Thanks for your response.
Quoting your statement "But it makes no sense to send this unless there 
was a matching prior sip request with the same sip URI."


If I understood correctly the earlier request prior to CANCEL is 
normally a sip INVITE. And in case of INVITE has been sent with the such 
format in FROM header then further requests like CANCEL can send it else 
not.


Do we have any reference on RFC that any SIP entity should not send sip 
 From header as like on CANCEL if INVITE has not sent with that way?


Spend some time understanding section 9 of RFC 3261.

It doesn't say it is incorrect to send a CANCEL without a prior matching 
request. But it specifies what the receiver of the CANCEL should do - 
that it should send a 481 response.


From what little you have said about the situation it sounds like this 
may have been sent as part of a test. If so the sender may intentionally 
be generating error cases to see if your implementation responds to them 
as it should.


Thanks,
Paul


BR///Rakesh

On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat > wrote:


On 8/4/22 8:11 AM, Rakesh wrote:
 > Hi Team,
 >
 > I could see in a sip CANCEL message From Header as below
 >
 > From: "test" http://ims.test.in>>;tag=3bbb9483d215d830c635372f8f181929
 >
 > is this correct?

Just looking at this, without regard for context, it is valid syntax.
(The userinfo portion of the sip URI is optional.)

But it makes no sense to send this unless there was a matching prior
sip
request with the same sip URI.

Each domain is free to define the userinfo portion of its sip URIs
as it
sees fit. This includes whether to support URIs with no userinfo. You
might want to consult an administrator for ims.test.in
.

         Thanks,
         Paul

 > Normally the From header is sip:user@domain
 >
 > As per ABNF grammar, the above one is also should not be an issue
as From
 > header but could let me know if I misinterpreted the ABNF grammar?
 >
 > BR///Rakesh
 > ___
 > Sip-implementors mailing list
 > Sip-implementors@lists.cs.columbia.edu

 > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu

https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors




___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip From header without user part

[Rakesh]

Hi Paul,

Thanks for your response.
Quoting your statement "But it makes no sense to send this unless there was
a matching prior sip request with the same sip URI."

If I understood correctly the earlier request prior to CANCEL is normally a
sip INVITE. And in case of INVITE has been sent with the such format in
FROM header then further requests like CANCEL can send it else not.

Do we have any reference on RFC that any SIP entity should not send sip
>From header as like on CANCEL if INVITE has not sent with that way?

BR///Rakesh

On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat  wrote:

> On 8/4/22 8:11 AM, Rakesh wrote:
> > Hi Team,
> >
> > I could see in a sip CANCEL message From Header as below
> >
> > From: "test" ;tag=3bbb9483d215d830c635372f8f181929
> >
> > is this correct?
>
> Just looking at this, without regard for context, it is valid syntax.
> (The userinfo portion of the sip URI is optional.)
>
> But it makes no sense to send this unless there was a matching prior sip
> request with the same sip URI.
>
> Each domain is free to define the userinfo portion of its sip URIs as it
> sees fit. This includes whether to support URIs with no userinfo. You
> might want to consult an administrator for ims.test.in.
>
> Thanks,
> Paul
>
> > Normally the From header is sip:user@domain
> >
> > As per ABNF grammar, the above one is also should not be an issue as From
> > header but could let me know if I misinterpreted the ABNF grammar?
> >
> > BR///Rakesh
> > ___
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip From header without user part

[Paul Kyzivat]

On 8/4/22 8:11 AM, Rakesh wrote:

Hi Team,

I could see in a sip CANCEL message From Header as below

From: "test" ;tag=3bbb9483d215d830c635372f8f181929

is this correct?


Just looking at this, without regard for context, it is valid syntax. 
(The userinfo portion of the sip URI is optional.)


But it makes no sense to send this unless there was a matching prior sip 
request with the same sip URI.


Each domain is free to define the userinfo portion of its sip URIs as it 
sees fit. This includes whether to support URIs with no userinfo. You 
might want to consult an administrator for ims.test.in.


Thanks,
Paul


Normally the From header is sip:user@domain

As per ABNF grammar, the above one is also should not be an issue as From
header but could let me know if I misinterpreted the ABNF grammar?

BR///Rakesh
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Sip From header without user part

[Rakesh]

Hi Team,

I could see in a sip CANCEL message From Header as below

From: "test" ;tag=3bbb9483d215d830c635372f8f181929

is this correct?

Normally the From header is sip:user@domain

As per ABNF grammar, the above one is also should not be an issue as From
header but could let me know if I misinterpreted the ABNF grammar?

BR///Rakesh
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors