Subject: [Sip] help:can\t find ioctl function in redhat 9

From: "vivian huang" <[email-masked]>
Date: Mon, 1 Mar 2004 16:52:48 +0800

Hi, all
I just run a sipsiproxd at my redhat linux 9. but I get this error messages in my /var/log/messages"

server siproxd: utils.c:365 ERROR:Error in ioctl SIOCGIFFLAGS: No such device 

Do any guys here know about this issue?

----- Original Message ----- 
From: "Tom Taylor" <[email-masked]>
To: "Gonzalo Camarillo" <[email-masked]>
Cc: "Christer Holmberg (JO/LMF)" <[email-masked]>; "sip" <[email-masked]>; "Rohan Mahy" <[email-masked]>; "Dean Willis" <[email-masked]>
Sent: Thursday, February 26, 2004 9:00 PM
Subject: [Sip] Re: INFO Documentation (was Re: Defining new requests)

> As a first step, I'll submit the Q.1912.5 annex as an I-D.  I expect we'll correct 
> it to use UPDATE rather than BYE as the model in Geneva in the next couple of 
> weeks, so what I submit will reflect that.
> 
> Gonzalo Camarillo wrote:
> 
> > Tom.
> > 
> > it seems that what you want is an update of the INFO spec, rather than 
> > fixing a few errata. I believe that we cannot meet your timeframe. In 
> > any event, it would be great we could start working on a solution for 
> > INFO in SIPPING, so that the ITU could reference it in the future.
> > 
> > Thanks,
> > 
> > Gonzalo
> > 
> > Tom Taylor wrote:
> > 
> >> Q.1912.5 is in the process of final approval.  Logging errata may be 
> >> satisfactory -- I'd have to check.  It would certainly be more 
> >> comfortable than reproducing the RFC with modifications in the ITU 
> >> document.  If the IETF acts within the next two weeks we should be 
> >> able to remove the Annex from the Recommendation.
> >>
> >> Here is the current list of changes as reported at the beginning of 
> >> the Annex.
> >>
> >> "The SIP INFO method is documented in RFC 2976. However, that RFC 
> >> refers to RFC 2543, the previous version of the SIP specification, 
> >> rather than to RFC 3261. The text of this Annex reproduces RFC 2976 
> >> with changes to reflect the updated reference.
> >>
> >> "The changes made are as follows:
> >>
> >> "Paragraph C.3.2.1: The references to the tables of RFC2543 were 
> >> changed to reflect the new table organization in RFC 3261.
> >>
> >> "Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that 
> >> show the header fields defined as presented in RFC3261. All additional 
> >> headers (additional to RFC 2543) used within RFC3261 were here set to 
> >> optional with two exceptions. The Reply-To (only optional for the 
> >> INVITE) and Call-Info Header (only used for INVITE, OPTIONS, REGISTER 
> >> to give additional information about the caller or callee) are not 
> >> used with the INFO method.
> >>
> >> "Paragraph C.3.6: The reference was changed to the current SIP 
> >> specification, RFC 3261.
> >>
> >>
> >> Gonzalo Camarillo wrote:
> >>
> >>> Tom,
> >>>
> >>> what is the timeframe here? As you know, we have had discussions in 
> >>> the past about either re-defining INFO so that it can only carry PSTN 
> >>> telephony signalling, or defining INFO packages. We could re-start 
> >>> those discussions, and once we reach a conclusion, clarify the rules 
> >>> to send INFO from the UAS within early dialogs in the same spec...
> >>>
> >>> If the ITU is in a hurry, other solutions may be better, like logging 
> >>> an errata against the INFO RFC.
> >>>
> >>> Gonzalo
> >>>
> >>> Tom Taylor wrote:
> >>>
> >>>> The ITU-T (Study Group 11, to be exact) had a different issue with 
> >>>> INFO: that the RFC depends on RFC 2543 rather than 3261.  As a 
> >>>> result, they picked up the content of RFC 2976 as Annex C.3 of the 
> >>>> ISUP interworking specification Q.1912.5.  If RFC 2976 ever gets 
> >>>> updated Annex C.3 can be deprecated.  In the meantime, this INFO 
> >>>> question means we have some maintenance to perform.  I think the 
> >>>> best solution will be to take Gonzalo's suggestion and say that INFO 
> >>>> follows the rules for UPDATE.  We already have a normative 
> >>>> dependency on the UPDATE RFC.
> >>>>
> >>>> Gonzalo Camarillo wrote:
> >>>>
> >>>>> Christer,
> >>>>>
> >>>>> would the ITU-T be happier if we log an errata against the INFO RFC 
> >>>>> saying that UASs can send INFO within early dialogs?
> >>>>>
> >>>>> Gonzalo
> >>>>>
> >>>>> Christer Holmberg (JO/LMF) wrote:
> >>>>>
> >>>>>> Hi Gonzalo,
> >>>>>>
> >>>>>> Thanks for your reply!
> >>>>>>
> >>>>>>
> >>>>>>> it seems that some people in the ITU-T are having some issues 
> >>>>>>> figuring out whether or not certain requests can be sent by the UAS
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> within an
> >>>>>>
> >>>>>>> early dialog. The confusion comes from statements like this one 
> >>>>>>> (taken from the INFO spec):
> >>>>>>>
> >>>>>>> "     Unless stated otherwise, the protocol rules for the INFO 
> >>>>>>> request
> >>>>>>>       governing the usage of tags, Route and Record-Route,
> >>>>>>>       retransmission and reliability, CSeq incrementing and message
> >>>>>>>       formatting follow those in [1] as defined for the BYE 
> >>>>>>> request."
> >>>>>>>
> >>>>>>> Since a UAS does not send BYEs within an early dialog, but a 
> >>>>>>> non-2xx final response instead, to terminate the dialog, people 
> >>>>>>> assume that
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> INFO
> >>>>>>
> >>>>>>> cannot be sent in this situation either.
> >>>>>>>
> >>>>>>> Let's try to keep this in mind and clarify this point when/if we 
> >>>>>>> define new SIP methods.
> >>>>>>>
> >>>>>>> In any event, the clarification to this issue can be found in RFC 
> >>>>>>> 3398:
> >>>>>>>
> >>>>>>> "From the callee to the caller, if a message is received by a 
> >>>>>>> gateway
> >>>>>>> before the call has been answered (i.e., ANM is received) it 
> >>>>>>> SHOULD be encapsulated in an INFO, provided that this will not be 
> >>>>>>> the first SIP message sent in the backwards direction (in which 
> >>>>>>> case it SHOULD be encapsulated in a provisional 1xx response)."
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The problem is that the ITU-T interworking spec doesn't reference
> >>>>>> RFC3398. The spec reference the INFO RFC, and that is also where I 
> >>>>>> think
> >>>>>> the usage rules should be defined (not in another spec, RFC3398 in 
> >>>>>> this
> >>>>>> case, simply using the method).
> >>>>>>
> >>>>>> The INFO RFC, as you said, currently says that INFO "follows the 
> >>>>>> rules
> >>>>>> of BYE" (whatever that means is another question :), and the rules 
> >>>>>> for
> >>>>>> BYE specifically says that it must not be sent backward before the
> >>>>>> INVITE has finished. If the INFO RFC would say "follow the rules of
> >>>>>> UPDATE" we would not have this problem, since the UPDATE spec
> >>>>>> specifically allows the use of the method before the INVITE has
> >>>>>> finished.
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Christer Holmberg
> >>>>>> Ericsson Finland
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>> This communication is confidential and intended solely for the 
> >>> addressee(s). Any unauthorized review, use, disclosure or 
> >>> distribution is prohibited. If you believe this message has been sent 
> >>> to you in error, please notify the sender by replying to this 
> >>> transmission and delete the message without disclosing it. Thank you.
> >>>
> >>> E-mail including attachments is susceptible to data corruption, 
> >>> interruption, unauthorized amendment, tampering and viruses, and we 
> >>> only send and receive e-mails on the basis that we are not liable for 
> >>> any such corruption, interception, amendment, tampering or viruses or 
> >>> any consequences thereof.
> >>>
> >>>
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sipJ*fj)bž	b²Øm¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£û"¥8b²X¬¶+¢³DY×¯zZ)™éí¡ûayÊ+y">º-¡Ê%RÇ¬Š˜¦¦W¦z{h®Ç,r‰n™¸šyÛŸ¢º®zËb¢{(Ë«éí²*T±ë"¦˜§‚'~Šà~Šç{^½éh¦g§¶Ê'¶š¦™bq«b¢z²*

---

From: Tom Taylor <[email-masked]>
Date: Wed, 03 Mar 2004 20:57:57 +0100

Latest word: we realized our annex really constituted a modification of SIP, 
something the ITU-T doesn't intend to do.  We've deleted it and are living with 
the consequences in terms of out-of-date dependencies on RFC 2543.

Taylor, Tom-PT [CAR:5N00:EXCH] wrote:
> As a first step, I'll submit the Q.1912.5 annex as an I-D.  I expect 
> we'll correct it to use UPDATE rather than BYE as the model in Geneva in 
> the next couple of weeks, so what I submit will reflect that.
> 
> Gonzalo Camarillo wrote:
> 
>> Tom.
>>
>>> show the header fields defined as presented in RFC3261. All 
>>> additional headers (additional to RFC 2543) used within RFC3261 were 
>>> here set to optional with two exceptions. The Reply-To (only optional 
>>> for the INVITE) and Call-Info Header (only used for INVITE, OPTIONS, 
>>> REGISTER to give additional information about the caller or callee) 
>>> are not used with the INFO method.
>>>
>>>> the past about either re-defining INFO so that it can only carry 
>>>> PSTN telephony signalling, or defining INFO packages. We could 
>>>> re-start those discussions, and once we reach a conclusion, clarify 
>>>> the rules to send INFO from the UAS within early dialogs in the same 
>>>> spec...
>>>>
>>>> If the ITU is in a hurry, other solutions may be better, like 
>>>> logging an errata against the INFO RFC.
>>>>
>>>> Gonzalo
>>>>
>>>> Tom Taylor wrote:
>>>>
>>>>> best solution will be to take Gonzalo's suggestion and say that 
>>>>> INFO follows the rules for UPDATE.  We already have a normative 
>>>>>> would the ITU-T be happier if we log an errata against the INFO 
>>>>>> RFC saying that UASs can send INFO within early dialogs?
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>>>> In any event, the clarification to this issue can be found in 
>>>>>>>> RFC 3398:
>>>>>>>>
>>>>>>>> SHOULD be encapsulated in an INFO, provided that this will not 
>>>>>>>> be the first SIP message sent in the backwards direction (in 
>>>>>>>> which case it SHOULD be encapsulated in a provisional 1xx 
>>>>>>>> response)."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> RFC3398. The spec reference the INFO RFC, and that is also where 
>>>>>>> I think
>>>>>>> the usage rules should be defined (not in another spec, RFC3398 
>>>>>>> in this
>>>>>>> of BYE" (whatever that means is another question :), and the 
>>>>>>> rules for
>>>> distribution is prohibited. If you believe this message has been 
>>>> sent to you in error, please notify the sender by replying to this 
>>>> only send and receive e-mails on the basis that we are not liable 
>>>> for any such corruption, interception, amendment, tampering or 
>>>> viruses or any consequences thereof.
>>>>
>>>>
>>
> 
> Use [email-masked] for new developments on the application of sip
> 

Use [email-masked] for new developments on the application of sip